Lightweight Architectural Design Process (LADP)

I went to see a mainframe customer about rearchitecting their system last week and went through a fairly specific set of stages as part of the process. Thinking about it I realised that I do tend to have a process which I aways use when undertaking an architectural design. This blog covers the process stages I use and I will follow up with other blogs which go through each architectural stage using the mainframe architectural design I did last week as an example.

So I actually have four stages that I use when doing an Architectural design, these are:

1. Business level overview and requirements

2. Present systems and constraints

3. Architectural techniques available

4. Architectural Selection

In practise these are not discrete steps but more rough phases which flow into one another, although I normally have coffee between 2 and 3! Looking at each of these phases in more detail:

1. This phase is where a representative of the business gives an overview of what the basic business functionality of the new system is (e.g. a contract management system) and the major businesses level functional blocks that exist or are needed (e.g. a pricing system or a billing engine). This is normally done as a set of business level blocks on a whiteboard. The major business process flow over these blocks is sketched in as arrows connecting the blocks. These become the business level transactions or logical unit of work. Then the business requirements are listed (e.g. support new pricing or reduce cost) either those that the present systems can’t provide or the new ones that are needed. An important part of this section is the realistic definition of the non functional or operational requirements, schedule and budgets (e.g. 23X5 and 70 real concurrent users).

2. A knowledgeable representative from the IT group such as the sysop for a mainframe system is the key element for this phase. They describe what application elements are in place today (e.g. the pricing system), how those work (batch, transactional) and what the systems and technology that they are implemented in today is (CICS Cobol, Oracle). The main interface points and levels to those systems are covered and any specific details about non standard elements of these interfaces and specifications are clearly understood.

3. An architectural technology representative, normally from a experienced and creditable IT supplier such as MicrosoftJ, covers the architectural levels possible within the proposed system and the architectural techniques applicable at those levels (e.g. DB access via DRDA). A key part of this phase is the description of the pros and cons of each of these architectural techniques. They then describe the main technologies and tools available to implement each of the techniques and the products that these are available. Any product or technology specific constraints should also be detailed.

4. Finally the two or three proposed architectures are drawn up based on the techniques from stage 2 and implemented using the systems from stage 3. These are assessed against the requirements from stage 1 and pros and cons for each architecture are detailed. All the stakeholders then give their input as to the preferred architectural design and a final candidate is selected and documented.

So this covers the basics of the lightweight architectural design process that I use. I will go through a typical example of the real life use of this process in future blogs.