Any company that does development work should have a specific development architecture that provides guidance into various aspects of the development process. If every development team works in a vacuum without overall guidance, they can make some bad decisions—decisions that could be bad for the development team itself or that are less than efficient for the company as a whole.
Previously, I explained how a development architecture, in general, can be used to provide guidance on the proper development life cycle approach to use for a project. Once the life cycle is chosen, the architecture can define the actual process used to build an application using that life cycle. In this article, I'll look at the other two aspects of development architecture—determining the appropriate technical model for an application, and the categorization and rationalization of the existing application portfolio.
Defining the technical models
Remember that one of the purposes of architecture is to provide guidance to decision making. When an application is being built, there are many decisions to be made—one of the most important is the overall technical design. The technical design is created after business requirements are generated, but before the detailed design and coding work begins.
If you look at all of the various applications today, you can start to categorize them into application types, or models. Let’s think about a large company that has over 200 separate applications. Regardless of the specific type of application and the type of data that is processed, you should notice a handful of application types. This might include Web applications, data warehouse applications, decision support applications, transaction processing applications, and reporting applications. You will also notice that certain types of models work better for certain categories of business requirements.
For instance, you might see that a Web application is better for external customers to order products from you. On the other hand, if you have an accounts receivable system processing 50,000 transactions a day, a Web application might not be the right one. Likewise, business requirements that call for the storage and retrieval of millions of customer order records might point out the need for a data warehouse application, rather than a traditional client-server application using normal database processing.
You don’t want to be in a position where you have chosen the wrong platform and software. Many times you won’t realize this until you start to do heavy systems testing, or worse, when the application goes live. That is way too late to have to rework fundamental technical design decisions. Development architecture can help by providing guidance as to the type of application that should be built, based on the business requirements.
Rationalizing the existing application portfolio
The third feature of development architecture is to understand and categorize what you already have. It might be surprising to know how many companies really don’t have a high-level picture of every application in their company. It should not be a surprise then that companies end up redeveloping similar software multiple times.
A few years ago, I worked at a large beverage company. We had just gone through a major reorganization in the IT development organization. In the past, we had been organized based on the various business units—finance, marketing, sales, etc. But after the reorganization, for the first time we were organized by business function. The difference in organization structure highlighted major redundancies in our business application portfolio. This organization allowed us to see that we had three major manufacturing systems in use. We also had multiple financial systems, marketing systems, and sales systems. Each sales system was unique to a particular business unit and the type of products they sold. From all accounts, this was a very inefficient use of company resources.
The major step in development architecture is to take an inventory of all the business applications that exist today, as well as any that are in progress. This sounds simple, but it can be a huge effort for a large company. You must first be very clear on what constitutes a business application. The ones supported by the IT development organization might be simpler to identify. But what about all of the applications that are created by business users, as well as the applications that are within IT, but managed and supported outside the development department? You must first decide the scope and definition of the inventorying process.
Next you must determine what information you want to collect on each application. There are many obvious characteristics, such as the purpose, the client base, the types of data processed, and the technical environment. However, there are literally dozens and dozens of pieces of information you could collect. You want to determine the information that will provide the most value, that is easiest to capture, and that will not require a huge process to keep up-to-date.
The application inventory is used for two main purposes. First, you can look for opportunities to rationalize wherever possible. One way to rationalize is to look for redundancies—that is, different applications being used for similar needs. For example, you may find two customer relationship management (CRM) packages in use. Further follow-up may reveal that you can standardize on one package.
You may also discover that you have development products used only by a small number of applications. For example, another company I worked for realized they had only one application using an older database. This visibility allowed us to expand an already planned enhancement project to convert the application to the standard database.
Rationalizing application inventory is an ongoing process
You don’t make major decisions to retire duplicate applications and older technology in a short timeframe. In fact, in a large company, you may need to look at a five-year plan to get to a more rationalized application environment. You may even decide that you cannot make a business case to eliminate all the inefficiencies. But this aspect of the development architecture at least gives you the information you need to make appropriate decisions.
The second purpose of the application inventory is to map requests for new development against the current business applications. This can be done as a part of the project approval process. When business clients are looking to build new solutions, they can refer to the development architecture to see if something similar might already exist. The people who are making funding decisions can also see what the new projects are, what business processes they relate to, and what applications exist in that space already. They can catch obvious duplications and ensure that redundant applications aren't funded.
More effective and efficient
As companies get larger, the chance increases that development decisions will be made that lead to an inefficient use of company resources. Development architecture can help by providing guidance into the development process at three key areas. First, the development architecture shows you the best development life-cycle approach for the initial development project. Second, the development architecture shows you the best technical design model you should use based on your business requirements. Third, the development architecture gives you visibility into all the applications in place and in progress, so that you don't reinvent a business application that exists today. All of this guidance allows the development work that is approved to proceed more effectively and efficiently, with as little rework and redundancy as possible.