Architectures are the building blocks of software. Good architecture would likely result in reasonably pain free development as well as . However, perfect architecture is almost never possible. In this series of articles, I will describe the basic process for designing software architectures. There is little difference between software and system architectures.
In this first article, I will try to point out some of the key business considerations (or drivers) when designing architectures. The they are:
- Time-to-market - how long will it take to built the architecture?
- COTS - can we use off-the-shelf software
- Product Lines - how easily will it be to extend in the future
- Suppliers (and relationship with them) - can we outsource the code and what would be the consequences?
- Expected Longitivity - will you need to and are you ready to support this for the next 20 or 50 years?
Time-to-Market
There is no point coming up with an architecture which cannot possibility be built in time for the market. By the time you finish, you would miss your golden opportunity to be first in the market. There is a real pressure to design architecture (product) as soon as possible to get the developers going so that the product can be released early. This usually means that architects frequently have to be able to think about architecture for quite some time in advance, even before there is a real investment in the product. In SDLC, these are known as feasibility studies. This means that when those 'overview' architectures are being created, the requirements are still very much unknown.
Reuse
Another important consideration when developing an architecture for a product is reuse i.e. will the company be able to use this product (or its part) in the future. If there is a need to design a bunch of data structures which need to be certified for a medical device, it might be worth making creating the architecture in such a way that these can be put into another separate component. The component can be sold separately or be used in another product. Creating a product which is one off, is very rare these days, but does happen.
COTS
There is a strong pressure, especially from the management side to use commercial off-the-shelf software. The argument being that it will speed up development and therefore cut the costs. This argument however is true only in part. For example, there is rarely the case for developing your own cloud because there are so many cloud providers already available. However, COTS may not be possible in some domains. For example, when developing medical software it might not be possible to reuse some existing library because it has not been certified. Because COTS are ready made, the companies may not offer the kind of support needed for particular development. If you need a certain feature in their software (e.g. you supply Microsoft Word with one of your solutions), and the feature is not there, then... well... deal with it. Another example may involve performance, what if you increase the load on the database and it doesn't perform as well as it should. Because the product is off the shelf. Finally there are deadlines to consider. What if a company promises to deliver some sort of feature by time X and doesn't deliver? You are under pressure to deliver your product and you cannot until they do their part.
Product lines
They generally allow to design an architecture in an 'easily' extendable fashion. You know exactly what you have to change to adapt the system to new environment (e.g. anti-lock braking system in a different car).
Relationship to suppliers
Some of the problem with COTS can be solved by using suppliers like processor suppliers, DBMS vendors and OS providers. However, the relationship with supplier is also quite tricky. They have to be trusted to deliver the component. Although past performance can be used as an indication it does not guarantee that this time round the system can be delivered. Indeed, complacency can be an issue and should be taken into account. British Airways will generally buy Rolls-Royce engines for their aircrafts, but every once in a while they would buy from somebody else, just to keep Rolls-Royce thinking.
The one benefit of using suppliers are skills in the company. If the company is no expert in concurrency, then it may be possible that simply outsourcing those critical components to other companies may be beneficial.
Expected Longevity
Generally, there is a pressure to design for longevity. This is true in part, however, will the product be in use for that long? Indeed, will the this company going to stay in the business for 10 years? Primarily the focus is on portability e.g. you don't want to be dependent on one operating system or just one database vendor. Not too long ago Sun went out of business and a lot of people were worried about Java. PHP community were worried about MySQL. These things do happen. System should generally be architectured in such a way that it can be ported from one platform to another without significant effort. Much closer and far more likely is the lack of support for certain libraries or different versions of the same library which cannot be used on the same platform (e.g. library doesn't work under .NET 3.5 because it was complied under 2.0 and they are not compatible).
This also means that the system has to be extensible i.e. adding new components without destroying the existing ones. Usually, in order to accommodate extensibility, product lines are put in place. With every new version, the architecture grows i.e. it isn't set is stone.
Finally, we need to able to consider legacy systems. In 20 years time, there will newer cooler toys. How to integrate the software? On one hand we don't want to keep the old database, but should we maintain multiple instances of the same database? Should you migrate? What if there are bugs in the new version?