Business Architecture for IT-Dummies

Stop, stop, stop, and please don’t go away! I know, you have seen the word „business“ in this title, and as a technical guy you have thought „thanks, it’s nothing for me”, but please give me a chance to explain why this topic is so important for you and us, IT architects, developers and testers.

We all love agile software development. It empowers teams that work in a close contact with the stakeholders, reacting on their feedback and delivering iteratively and incrementally product increments. However if we look at this “close contact with the stakeholders” we can oft assess that our “close contact” and as a result the information scope and the quality we can get, is quite “limited”. Mostly, we have only contact with one person who is responsible for the definition of all requirements (is he or she a product owner in case of Scrum or a business analyst or a product manager in case of other frameworks, it doesn’t matter). Because it is just one person, it is very seldom that he or she has holistic (means ultimate) view and understanding of the customer’s business. And this understanding is one of the key concepts needed if we want to deliver a good product and have a satisfied customer at the end of the project.

Only if we understand what we do, we can do it effectively.

The fastest way to understand something completely new is to analyze the model of it. In case of a software system, if we want to talk about its model, we have to talk about its architecture. One of the well-known frameworks allowing almost complete description of the software architecture is the “4+1 architectural view model” designed by the P. Kruchten:

This model contains 4+1 views allowing description of the various aspects and requirements of a software system:

• Scenarios represent well-defined interactions between external actors (users or systems) and the software system;
• Logical view is concerned with detailed functional requirements;
• Process view aka Quality view deals with the quality requirements (and btw. has nothing to do with the processes as such);
• Physical view aka Deployment view describes the environment into which the system will be deployed and its dependencies;
• Development view, as easy to presume, describes the system from the development point of view, including technologies and frameworks.

I use this model in a gently modified form (with some additional views) very often in my projects, because it makes me confident that I haven’t forgotten any important or even critical architectural aspect. I can only encourage you to do it as well.

However, even if this model contains some business elements, it is far away from the holistic view on the entire business. We need something that is more generic, we need the enterprise architecture. In its simplest definition enterprise architecture describes the alignment (understood as harmonization) between the IT-architecture and … the business architecture:

As described above, the IT-architecture can be modeled using the “4+1 view model”, so we can depict our enterprise architecture again as follows:

The last question is what to put into rectangle with the question mark? What is actually business architecture?

My preferred answer to this question is the notion designed by Chris Reynolds and described in his book “Introduction to Business Architecture” (2009). It might be a small surprise for you, but he has also used the idea of various views as a foundation for his model:

Reynolds defines business architecture as follows:

Business architecture is a model that represents various views of a business, including the Goals, Facades, Processes, Communications, and Business Entities views. It shows what state a business wants to be in, as well as where a business currently is. It also outlines a list of the right projects to work on, as well as when to work on them to get to the envisioned future state.

Business architecture gives you a holistic model of your business. The model depicts the current state of your business as well as the future state you are striving to achieve. This holistic view helps you understand what your business currently has in the way of a model. This understanding includes:

• Goals the business is trying to achieve;
• Facades means how the business interacts with all aspects of its environment, including customers, suppliers, and regulatory bodies;
• Processes means how the business operates internally to support its environmental interactions;
• Communication means how the business communicates internally and externally;
• Entities that describe what information the business deals with.

The current state of all of these things describes the business’ current fit, while the future state describes how you want it to fit. This future state gives you the opportunity, through the use of the business architecture model, to ensure a better fit between the business and its environment than it currently enjoys.

Given this information we can refine our enterprise architecture diagram to get the complete view of it:

As you can see, if you want to assure you can deliver right product to your customer, you have to be aware of all aspect of the customer’s enterprise architecture depicted above. Your core part is clear the IT-architecture, however a good set of answers on the questions regarding business goals, facades, processes, communication and entities will give you a much better understanding of the customer’s business, understanding of the state it is now and the envisioned state it should be with the help of your software solution. And if you think, the enterprise architecture is for big organizations only, it is wrong. Even if the name enterprise architecture it suggests, enterprise architecture exists in every organization that needs an IT-solution to run its core business.

So please be prepared to communicate with the customer about your IT-architecture as well as about his business architecture, if you want to write a success story at the end.

If you want to talk about these fascinating topics just join us @codecentric’s Agile Architecture Xing Group