Partager via

Lightweight Architectural Design Process (LADP)

  • Article

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.

Comments

  • Anonymous
    April 01, 2004
    Very good information. A real life example would make things more clear.
    one more question..what is your opinion about Extreme Programming..its approach in design and implementation of a project
    Thanks
  • Anonymous
    April 01, 2004
    Yup, i'm going to do that. I will also drill down into the actual application architecture rather than the system architecture as detailed here.
    XP has a place, with the right project, people and culture it can work well. It's not always the answer and in my opinion it's only the answer for about 40-40% of the projects out there.
    Some of the techniques of XP are valid for any project however, continous build and test springs to mind.
  • Anonymous
    April 01, 2004
    Thanks for your reply... I had some more questions if u have time...

    1. Since ur a Microsoft employee, does it influence the selection of architectural technologies available when making decisions....like, selecting a MS product (for a sub system) even though u feel that there could be better alternative available out in the market?

    2. Have you come across a situation where in you have walked away from design table saying that MS technology is not at all suitable for a particular product architecture?

    Thanks for your time.
  • Anonymous
    April 01, 2004
    Ouch!
    Yes it does influence my selection because I know MS technologies better. I normally only work with products that I believe in and think are the best, frankly I couldnt do a job where that wasnt true. I avoid products and technologies (Microsoft's or other companies) where I dont think they are the best so I dont normally come across the problem.
    Yes, I have said that MS technology was not the best choice for a particular customer in a specific situation but it is rare. I belive that the important thing is that the customer gets the best solution for them and I am glad that it's normally from MS. It hurts when I have to say that I think our solution is not the best.

















  • Anonymous
    April 01, 2004
    wow!! you spoke like a true professional. I totally agree with your answer. There is lot to learn form u and will keep looking for your future posts. Thanks again