- Plan A;
- Plan B; and
- Enterprise approval.
The roadmap sets the path. The timetable sets the pace. Plan A lays out what needs to be done. Plan B lays out what needs to be done in case plan A fails. And the last item proves the business value of the planning and preparation made.
It’s almost simple. It’s almost easy. But this is just the beginning…
- Their capacity to provide future support;
- Their capacity to deliver enhancements at the most acceptable turn around time;
- Their capacity to advance as the technology itself advaces.
The software development team is the source of the action in terms of making software a reality. While the management, fr example, may have its share of the motivation, the team by itself should be driven by its own energy and spirit.
- Their capacity to keep raising the IT organization’s value proposition;
- Their capacity to deliver to the basic expectations of the enterprise;
- Their capacity to ensure the continuous advancement of the IT organization as the whole IT world advances.
The IT organization, first and foremost, values the enterprise it serves. It is understandable for the enterprise to expect the highest level of perfection possible on its IT organization. This challenge is best accomplished for as long as the IT organization could raise its value proposition and continue to invite investments that add value to the enterprise.
Information technology (IT) is part of most enterprises today. And that is exactly where IT stops: as part of the enterprise. The enterprise has its own vision, mission, plans and governance as affected by many factors not exclusively related to IT. In fact, IT is just one of the many players contributing to the enterprise’s ecosystem.
For most companies, IT is not the center of their businesses, although IT can inspire and motivate innovations of new business areas; improve operations and, at the same time, help to reduce costs; or provide the tools to enhance decision making in order to give the enterprise its competitive edge in the market or in the industry it belongs to. IT is a service and the IT organization simply serves it.
The enterprise is in control of its IT and never the other way around. IT Governance and, its key component, Enterprise Architecture in computing are important knowledge in making sure that the enterprise is in control of its IT organization. Accordingly, the enterprise must establish the IT organization with respect to its potential evolution and advancement. There should be a balance by which the ecosystem allows for growth. This balance should, therefore, be part of the principles in creating the enterprise’s IT roadmap.
The enterprise’s IT roadmap helps shape the management and style of software development. Waterfall or agile? Compact or distributed? Components or services? These are some of the questions that may be raised as the IT organization matures. Regardless, what matters is that the IT organization’s software development team is aligning their efforts to the plans of the business.
Software development for the enterprise is different from simply developing software products. Enterprise software development aims to deliver software products with the enterprise in mind. It should serve the current and future needs of the business. The readiness of software to survive the future is critical to its overall success. This challenge, on its own, is very difficult as it requires business knowledge, involvement and foresight from the software development team itself.
The ability of the software development team to plan its structure and processes is crucial. How it asseses itself and its growth affects the direction it takes in all aspects. There are pit falls to watch out for. There are pros and cons to consider. Still, what is important is that the team recognizes that it is existing and working for the enterprise — no more, no less.
The disciplines, principles, strategies, science, approaches and techniques to be followed by the software development team define itself in the enterprise. In reality, the simplicity and the complexity of all these depends on the capacity of the enterprise to support them. There are cases when the software development team should compromise for the sake of the enterprise. This is natural and should be highly considered and factored in to ensure success.
Enterprise software development is generally easy. Compared to Microsoft’s business to create generic software products to target various industries and enterprises around the world, enterprise software development focuses on a much more controllable audience. Although, this fact does not limit the IT organization to plan itself beyond the designs of the enterprise, the IT organization is, first and foremost, expected to prioritize the enterprise as its base customer. In line with the IT organization serving IT services to the enterprise, enterprise software development should, likewise, be a service to deliver software for the enterprise.
There are a lot of "frameworks" available out there for .Net developers to use. Examples are the Microsoft Enterprise Library, Spring.Net, NHibernate, the Castle Project and Rockford Lhotka’s CSLA.Net. Although these products have various offerings and different target problems to solve, they are essentally called frameworks. These frameworks help fast track development by providing core features and functionalities that may, otherwise, take time to develop. They have their advantages. But they may also be traps that designers should be careful about.
I don’t really intend to re-invent the wheel, but, I prefer building my own framework and similar "utilities" as some developers would like to call them. I base my frameworks from these existing products, not exactly like re-inventing the wheel, but rather with the intention of simplifying the wheel.
I also like the fact that the frameworks I create are named after the enterprise it targets (<company>.Library). There is a sense of ownership and it can be customized easily to adapt to the capacity of the enterprise’s IT organization. I also like the fact that the frameworks I create can be easier to use, maintain, manage and support. They are also flexible and, likewise, extensible by design.
My framework, like the other frameworks, has its own pit falls. It has the same problems as the other frameworks. The most important consideration is the fact that better technologies always get invented even while you write your own framework. For example, the currently coined ADO.Net vNext promises its own entity framework competing against Spring.Net and NHibernate. ADO.Net vNext is new, but it is the direction of .Net.
The problem that ADO.Net vNext solves is the direction of the developer community in general. Most Java developers have been embracing this model for a long time. I am not sure yet, but the possibility is high that, in the end, .Net designers should highly consider using it instead of Spring.Net and NHibernate regardless of who is mature or not.
Why do I write my own framework? It’s simply because I want to stick as close as possible to the .Net Framework. Not that I avoid third-party products. But if you can, why not?
- Input – these are the data that are identified in the requirement as directly provided by something external to the actual software. Input may also be something that the software itself intends to pickup or gather from pre-determined stores.
- Parameters – these are the data that serve as the conditions by which data may be sourced, processed and delivered. Parameters are often part of the configurations or the givens in the requirements.
- Output – there are the data that serves as the expected results of the software’s processing of the Input and the Parameters through a set of rules. It is most important to know the Output. Otherwise, the whole point of abstraction is lost.
Abstraction is strongly about data and identifying them. It’s not much about what you plan to do with them. What matters is that, in the first place, you know about them.
- When operational issues come in, the software may lack manageability and maintainability;
- When technical support and enhancements come in, the software may lack extensibility and flexibility;
- When the enterprise starts to grow and change, the software may be difficult, if not impossible, to keep up to date.
- rules; and
- Structuring the IT Organization – a look at an ideal structure for an IT focused organization
- The Structured IT Organization Process Cycle – a look at an ideal process cycle for an IT focused organization
- Solution Infrastructure and Architecture – a look at some effective solution designs and practices
- Designing Applications for the Future – an architectural perspective with the business in mind
- Enterprise Software Development – a look at some effective disciplines and practices in developing for the enterprise