Steps to create enterprise/system Architecture

In those lines I’ll try to explain the steps that I’m going through while creating architecture for enterprise or system. First of all, to be clear, let’s define architecture. As I see it, architecture is a set of ideas back up by set of rules that should be followed by system’s designers and developers to ensure that the building system/s will solve enterprise/system needs by adhering enterprise rules and constraints. That set of rules should be published as diagrams and documents, describing chosen architecture and what designers and developers should do in order to fulfill the laying architecture. If it possible it’s better to create, as the first byproduct of architecture process, a infrastructure that will be used by system/s. this infrastructure supply both better enforcement of architecture and shorten system development process.

I don’t see any different between enterprise and system architecture regarding the steps needed to defined them. The steps are the same just the scope different. While enterprise architecture should set architecture to solve entire enterprise goals and needs, system architecture should do the same but just for one system in the enterprise. Yes, enterprise architecture should take in account how to integrate all systems in the enterprise but system architecture should do the same to all system components. Actually there is just one difference between enterprise and system architecture. System architecture should follow enterprise architecture. In the rest of those lines I’ll address just architecture as it for enterprise or system use.

As I see it, there are 7 steps that should be followed to create better architecture. Every one of those steps depends on previous steps. Flaw detected in every step could end up with changes that should be made to previous steps. I’ll try to go through those 7 steps and to describe shortly what the aim of each step is.

Step No.1 – Business needs analysis.

This step doesn’t use any technical abilities, nevertheless it’s the most important step. I saw more then once architectures that drives from technical viewpoint and not from business viewpoint and I think that’s completely wrong. Your architecture should be foundation for solving enterprise need/s. those foundations should be the base for system developing. Therefore in order to solve problems you need to understand first what are enterprises needs, problems and constrains. You can’t base your architecture relaying on technical solution. Technical solution are the tools that you use in order to solve business needs but they shouldn’t be one of the base problems that you trying to solve.

The output from this step should be list of all the enterprise needs, constraints and rules. Eventually your architecture should address all of those points in the list. For example such a list could contain the following points:

• Our goal is to develop competitive intelligent system of systems (SOS) to enable enterprise to be aware of potential threats.
• Every system represents one entity in our competitive intelligence SOS.
• Every system (entity) build from 3 layers (Visualization, business logic, and data provider). We want any system to supply and consume every one of those layers from/to other systems.
• Enable the user to show different entities visualization on single page is a must. User can add visualization layers of entities dynamically.
• Other entities (systems) should be added to SOS with minimum work.
• From the user point of view, he is working against one system. He doesn’t care that systems develop by different development groups.
• All systems should be available 24*7. Even in maintains process.
• We want to minimize deployment of software to user’s station.
• Systems should be followed the same development paradigm and system flow in order to enable using and adding infrastructures services.
• Systems and infrastructure should be based on Microsoft solutions :-).

Step No.2 – Set architecture.

In this step you should follow one of the architecture frameworks in order to create match architecture. Usually most of the framework split this work into several viewpoints. Every viewpoint set different aspect of the architecture and usually every viewpoint is depending on the previous viewpoints. Most infrastructure split architecture into 5 viewpoints:

1. Business - which we already describe.
2. Information – this viewpoint deals just with the data aspects of your architecture. In that viewpoint you should set which data your architecture should address (data storage, state data, transactions, etc’) and how you decide to achieve it (relational DB, OODB, ORM, optimistic lock, etc’).
3. Computational – here you need to decompose needed functionality and build components that should perform needed functionality.
4. Engineering - this view point should set given architecture needed to create components and where every component should work eventually (layers, nodes, physical position).
5. Technical – just in the end of the process after information, Computational and engineering set up it’s time to decide which tools we should use in order to fulfil the previous requirements (Oracle, SQL Server, cache AB, Java spaces, etc’).

In this step I usually use to go through proven architectural patterns in order to find the right architecture for the given need with respect to business needs, rules and constraints. One piece of advice, use just proven patterns. Don’t tempt to use patterns that not used in production - real life systems, even if you convinced that this architecture pattern match perfectly your needs. Using non proven patterns could cost you a lot in developing stage. You can find list of well known patterns in “Patterns of Enterprise Application Architecture” by Martin Fowler.

Step No.3 – even if you use proven pattern, write skeleton that prove your architecture.

After you’ve got in mind what architecture you are going to use test it. Write simple system or systems based on the chosen architecture to demonstrate you ideas and test those ideas against enterprise needs. I also add checks for performance and scalability. Keep those skeletons you will need to use them in up coming steps. If your skeletons find out any problems or you find out that one of enterprise needs, rules constraints didn’t meet go back to step 2. Don’t continue to step 4 until you totally convinced that you meet all your targets. In this step I use to show my skeleton systems to several group leaders and hear what they have to say about it.

Step No.4 – write and publish architecture documents and diagrams.

This is the tedious step but important one. The output should be several diagrams that demonstrate the architecture and documents contain every one of the architecture rules and constraints that yield from the architecture that you chose. Try to split those rules by the viewpoint that I mention in step 2. Don’t forget that your documents will be the base for designers and developers so write them as clear as you can.

Step No.5 – convince architecture users why this architecture is the right one.

Convince other is the toughest step. After you sure that you finished with architecture and published it so others can read your architecture it’s time to convince the people that goanna use your architecture that this is the right choice. If your user doesn’t convince that you done the right decisions they probably try to workaround your architecture. Use your skeleton system together with a lot of patience and start convinces groups of your users that your architecture works. Keep your mind open, if your users come up with problems that influence development process refer that issue. If that step raise problems that needs changes in your work that you done by now, change your work. It’s better to adjust your work to developers needs then they won’t accept your work and won’t follow your architecture.

Step No.6 – write infrastructure that support your architecture.

After you convince everyone that you have the right architecture it’s time to write down infrastructure that will support your architecture (if you set MVC as visualization pattern, supply infrastructure that implement MVC). That infrastructure should help developers to follow architecture with minimum effort. Architecture infrastructure is usually good place to implement system infrastructure that set at engineering viewpoint.

Step No.7 – engage in development process.

While system is developing find away to engage in the development process (I use to help programmers and designers in daily problems). Engaging in development let you check if your work really good. You can see if chosen pattern is hard or easy to implement, if the framework really help developers, if architecture really meets system goals, if you missed some point in your work. Shortening it’s a grate way to get feedback about your work and to learn from mistake to make your next work more perfect.