Every time the word "Architecture" comes along in an IT audience it means something different in each and every people's mind. The level of maturity and experiences in IT are so broad and so wide that these communication gaps tend to drive discussions to the realms of surrealism. Things are in fact much simpler, and this article will drawn from a simple example to explain what are the different levels of architecture out there, trying to shed some light over a subject that seems so blury for some people.
The Vet Hospital
Imagine a veterinay hospital. Pets come in, pets are admited and discharged, pets are seen by doctors, or they come because of some emergency. All kinds of pets. In terms of health life cycle the hospital has to keep track of vaccines, and other critical milestones, so they can contact pet owners. Keeping track of all this plus managing the diagnostics, medical procedures, and the clinic requires business procedures. Any business has procedures, which are made of functions, some of them resusable from one to another. For instance: scheduling a medical procedure. Sounds simple, but you have to know that for each different type of procedure there are specific requirements, and resources that need to be procured in a timely fashion. So a function might be comprised of sub-functions. Some parts of these procedures might be private (Vet Hospital staff only), and others might be available for the pet owner, which is a kind of "public" characterization.
I don't want to make you head spin right now, just draw your attention for what is the role of a business architect. What? Is that the name of the people that create these tangled procedures? Well, probably not in a Vet Hospital, but on a car manufacturer where the procedures are 100x more complicated, the business architect is key in defining what makes up a business process and in what functions it relies, hierarchies and so on.
This practice is called: Business Architecture. Automation is key in this area, so these business architects rely on different tools to help them manage the complicated business processes and to manage those flows and dependencies. These are called BPM tools. We are not in IT yet. Hang on.
The Late Report and the costs of doing things detached from the procedure
There will be a day where businesses need to change the way they do things. Either because of a new product, service or simply because there's a smarter way. Unhappy customers are also one of the key suppliers for input that a specific service is not working and needs to be changed. What is the impact of changing a Business Process? Well if you don't have it documented (using BPM tools or any other type of tools), you'll have a hard time understanding that impact. The real reach of a change is never assessed 100% because of the time dimmension, but let's keep this on the realm of the predictable. A simple example in our Vet Hospital would be a clinical report that the pet owner needs in order to submit it on the pet insurance company. If the Hospital does not send him the clinical report on a timely fashion, the pet owner might come back and ask for it. If even after this that report is not sent, the lack of this report might make him lose the right to be reimbursed on XYZ amount of money. He files a complaint. Nothing happens. He sends an email to the general manager, and all of the sudden informal processes are triggered and things seem to work. Sounds familiar? A late report is again a simple example of a procedure going wrong. What if this would happen in the automotive industry? Well, it's when you hear it in the news that a certain manufacturer is calling all the owners of a specific model to replace one or more defective parts.
Flexibility versus Time To Change
In business architecture you should never confuse flexibility with the time it takes to implement a specific change. Flexible is not always synonym of good. A flexible architecture means that is open to change, but this flexibility comes with a price. The time and cost that it takes to implement a change in a flexible environment might not compensate at all. On the other hand some rigid rules, that only allow a very small set of changes, might operate at an optimal level, and allow for more cost effective changes. Flexibility is sometimes the worst enemy of change and performance. Who would have thought that?
What other types of Architecture are out there?
When processes, matrices, functions and all that jazz needs to me automated that is when you think about IT services to support them by implementing all the logic and information management procedures. Services that comprise a logical set might be called Applications (let's go light on the definitions), and these applications support business capabilities. Some are stand-alone capabilities, and others need to talk to each other. The architectural blueprints where you document this is called Applications Architecture. The information that these applications gather, process and save, will have a lifecycle and will be used as source for Business Intelligence systems, and all these flows are concerns for the Data Architecture or Information Management Architecture. This is the realm of Information Systems Architects.
When these systems get implemented using software and hardware technology that is when you enter the ground of IT and Technology Architecture.
TOGAF: A guiding light
All these types of architectures are drawn from TOGAF which stands for The Open Group Architecture Framework, a type of concensus to which everybody contributes, trying to create a common language around architecture. TOGAF is about three pilars:
- The method, called ADM (Architecture Development Method)
- The approach: the base for an Enterprise Architecture practice
- The models: reference architectures
TOGAF was created from the US Department of Defense Technical Architecture Framework for Information Management (TAFIM), but today is suposed to be a method and a framework that supports the practice of Enterprise Architecture (EA). The practice of EA today is very much focused on Capability Based Planning and this is something that specific layers of people inside an enterprise are used to deal differently. Because EA sits between Business and IT a common language has to be used, and this is where TOGAF should be seen as a guiding light in the effort of bringing all types of architects together.
Let's imagine that a new business capability needs to be implemented. When posed with this challenge the IT department can use one of these strategies:
- Acquire a commercial of the shelf software package, with limited customization options
- Acquire a packaged solution from a leading vendor, with tons of services on top
- Develop a new IT solution for that capability, either in-house or using an army of consultants
- Extend the current solutions so those capabilities can be covered
Let's step back a bit, going back to the Vet Hospital. An example of a new capability might be: "Give our customers, pet owners, the ability to track the treatment process on an online platform". If we get into the head of different people, we'll find different views of how to address this need:
CEO - This will create a new and innovative service that will help me differentiate from competition and expand my business.
CFO - I wonder how much will it cost and if we can get measure the value taken from the money we'll invest on this.
CMO - I will launch a campaign that will leverage this change as a key factor for people to choose our Hospital instead of the competition
CIO - I only hope I have enough resources to finish this on time and on track.
CTO/Chief Architect - I need to assess exactly what is the depth of change this new capability will pose on our systems
IT Manager - This new platform has to be in sync with our current IT strategy
All these stakeholders have different views and this is the core of any architectural framework, specifically TOGAF's. Requirements will steer the way. But these need to be in sync with several principles, some more written in stone than others. Some of these principles are quite ridiculous in IT, like "Our strategy is to use Oracle Database on AIX". This is not a strategy and not even a principle. TOGAF helps enterprise architects create those architectural principles, aligned with the business strategy, so any new capability that comes along would know where exactly does it need to fit and how.
Going back to the example, the possible questions that the enterprise architect could pose to each stakeholders in order to get a deeper understanding could be:
CEO - This will create a new and innovative service that will help me differentiate from competition and expand my business. EA questions: What other innovation initiatives are taking place? What other strategies are being thought to "expand the business"?
CFO - I wonder how much will it cost and if we can get measure the value taken from the money we'll invest on this. EA questions: Besides ROI what are your other concerns regarding this project?
CMO - I will launch a campaign that will leverage this change as a key factor for people to choose our Hospital instead of the competition. EA questions: How does this campaign is directly connected to the capability? or Does the future system needs to account for vouchers, promotion codes, testimonies gathering? or Do you feel the need to measure the success of this new capability? and How?
CIO - I only hope I have enough resources to finish this on time and on track. EA questions: What type of resources are you planning to use? Do you feel you have them all? What is missing?
CTO/Chief Architect - I need to assess exactly what is the depth of change this new capability will pose on our systems. EA questions: Keep me posted on that assessment!
IT Manager - This new platform has to be in sync with our current IT strategy. EA question: Tell me more about your IT strategy (I know I'm going to regret asking this!)
About Enterprise Architecture Management
The practice of EA is not easy and is not the purpose of this document to explain it. However you can read more about it in this excellent document: http://www.detecon.com/de/publikationen/studien/download/study_downloaded.html?unique_id=68710
Luis Moreno Campos
Enterprise Architect for Oracle Europe, Middle East and Africa