Minimal IT - How to choose architecture and technology

8 February 2011

How to choose architecture and technology

Architecture and technology decisions need to be driven by IT management requirements more than by functional business requirements.

We have plenty of methods for analysis and design, for project management, for programming, and for evaluating software. But we rarely take a methodological approach to defining an overall architecture and selecting the main technical components within it.

Part of the reason for this is that major architectural and technology decisions have usually been set by earlier acquisitions and projects, and, rightly or wrongly, new solutions tend to fit into what has gone before.

But if it is not already set, how should you define architecture and technology?

I do not think that you can start with business requirements, or even general non-functional requirements such as security and usability. Business requirements translate into IT functionality, and most modern architectures can deliver pretty much any functionality. You need to start with broader IT management requirements, such as:

Constraints of existing architectural choices or of chosen solutions.
Which parts of the solution are going to be developed and run in-house or externally.
Availability of skills.
Need for longevity of the solution.
Whether acquisition cost and running cost are significant factors to the organisation.
The degree of independence of the different business areas served.
The size and location of the user population.
Likely availability of packaged application software.

Once you understand the main IT management requirements, you can consider the architecture by splitting the overall solution down into major chunks. You will need different chunks for independent business areas. You will need different chunks where pieces are outsourced, or where you may use packaged software. If longevity is a major concern, you need to split solutions so that different parts of the solution can be replaced independently, and pay attention to standards.

Once you have the major chunks, pick sets of technologies that fit into your architecture, which are conventionally used together, and which meet your IT management requirements. These may well be subsets of one of the major families of technologies, such as Microsoft, Oracle, open source or IBM mainframe. However, just because you pick, say, Oracle, it does not mean that every product from Oracle is appropriate. You still need to think through which pieces of that family meet your IT management requirements, and steer away from the ones that do not.

This is not in any way a detailed method, but for me the key points of defining an architecture and picking the right technology are:

Base major IT architecture decisions on how you need to run your IT rather than what you want to do with your IT.
Remember that management is more important than technical elegance. Often IT management will require that you break up the architecture even when the technology would allow tighter integration.
Although most of the time you will pick one of the major technology families, make sure that you use it in a way that is consistent with your management requirements, and not blindly adopt it all as a standard.