The establishment of a detailed development architecture will provide your organization with decision-making guidance. Such a framework can guide decisions concerning the application development life cycle, reducing costs and increasing efficiencies.
In general, IT architecture is a framework. It's a structure that provides guidance to help make the best use of resources on an organizationwide or companywide basis. There are a number of frameworks, or architectures, in your IT organization. For instance, you can define a technical architecture that identifies your technical products and tools and when it is appropriate to use each. You can define a data architecture that describes important data fields and characteristics about each one. In this article, I will focus on development architecture.
I am defining development architecture in a broad sense to include three major areas:
- The development life cycle and processes used to build business applications
- The application models that show the appropriate technical design that will best fit the business requirements
- The inventory and categorization of the business applications that exist within the organization today. (In some companies, this area is called application architecture, but I am including it in the definition of the broader development architecture.)
Let's look at the development life cycle in more detail to see how it can affect your application development environment in a positive manner.
Application development process
The first area of development architecture is the processes associated with your development life cycle. Defining the development life cycle is a good exercise for companies of all sizes. If your company produces software for a living, you probably already have this in place, although I know of some companies that still don't.
There is a fair amount of the development process that requires the creativity and skills of the individual analysts, designers, and programmers. However, there are also many aspects of the life cycle that can be standardized. For instance, there are many ways to collect business requirements. However, there are certainly some ways that are better than others. There are also many techniques available to gather requirements—from personal interviews to surveys to group meetings. There are also certain proven techniques for testing. Your development architecture might provide an overall testing process that is applicable to general projects, but which allows some customization of the processes based on the specific solution being developed.
There are also many ways that applications can be developed. You could use traditional waterfall methods (e.g., analyze, design, code, test, etc.) or you may use a rapid application development (RAD) approach of building the solution in successive smaller increments.
One of the strengths of architectures is that they provide guidance to assist with decision making. In this case, the initial guidance would come in terms of the type of development life cycle you should choose. For example, there are some projects where it is better to use a waterfall approach rather than RAD.
Before the project gets too far along, the project manager should evaluate the business requirements against a predefined set of criteria. These criteria lead to guidance on the type of life cycle to utilize. For example, if the solution is heavily online and the requirements aren't well known, it may be that a RAD life cycle would be better. If the solution is heavily batch oriented and requires a lot of integration into other current applications, a traditional waterfall approach might be a better choice. If the solution is actually a major enhancement to an existing application, an enhancement life cycle may be more appropriate.
Setting up the development life cycle
Anyone who has created methodologies knows that they can be very difficult and time-consuming. They can be, but they don't have to be. You can purchase development life cycle methodologies to use as your starting point or you can get a group together and brainstorm the processes.
One critical decision to make is the level of detail that you provide. My preference is to provide enough detail that you give guidance to the project managers but not so much detail that the methodology gets cumbersome. You can spend a year defining the life cycle at a very detailed level, but there is a much earlier point where you have covered 80 percent of what the project manager needs to know. That is the point where I would recommend the process ends.
In terms of guidance, you also need to determine whether portions of the life cycle are mandatory. If so, these are considered company standards that everyone must follow. For instance, you may have standard templates that must be used at certain points in the life cycle. Your life cycle can also issue guidelines that are recommendations, but not absolutely mandatory.
A guide to decision making
Development life cycles provide guidance as to how applications should be developed. This type of life cycle will save project managers the time and effort required to create development processes from scratch each time an application is built.