Demystifying Enterprise Architecture

 

I have been in the IT world for more than 15 years now, where the last 10 years I spent in different architecture positions – ranging from solution to enterprise architecture. In all that time, many buzzwords were coming and going, hype cycles were rising like tsunamis and then gone like nothing ever happened. Exciting new technologies, tools and methods were showing up, people would master them or dismiss them and the world would go on. Hardly anyone turned their head back and asked what happened to that thing.

But during all that time, one question remained in the same time both unanswered and answered in so many ways that the correct one was almost impossible to spot. That question can almost become a benchmark for what ambiguity really means.

Let’s start with that question: “What is Enterprise Architecture?”

According to Gartner Group: “Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution.”

But in reality…

But let’s start from the beginning…

Architecture is what everyone is taking about. When a new project is starting – “We need to get an architect to design it”. When an organization is going through a transformation – “Architects need to drive it”. When something goes wrong – “It’s architecture that we need to blame”.

When we talk about architecture, there are two levels that we need to differentiate:

1. Solution Architecture
2. Enterprise Architecture

Solution Architecture is almost self-explanatory. Your client confronts you with a problem and you need to find a solution to that problem.

Solution Architecture is not just about IT architecture. Solution architecture can apply to different domains. If you are designing a new business process then we are talking about Business Solution Architecture. If you are looking at the infrastructure setup of a new data center, then that is Technology Solution Architecture. Design of a new web application would be Application Solution Architecture. Defining new big data concepts like data lakes is Data Solution Architecture. And probably the last one would be Security Solution Architecture when you are designing an identity management solution for example.

Often these architectures do not live in isolation and if you are truly lucky, you might be joining a project where you need to cover all these domains under one Project Solution Architecture.

OK, that was easy part.

Now back to our mysterious topic – Enterprise Architecture.

In practice, all you need to do as an enterprise architect is to define these three things:

1. As-Is state
2. To-Be state
3. Transitional states

And that’s it!

As-Is state describes your current enterprise. What business services your company offers, what business capabilities it has and what are the processes behind those. As-Is is also capturing all the applications your company runs as well as the entire infrastructure that those applications are running on top of. Ideally, As-Is state should have all of those artifacts linked together so that you can navigate this linked tree of information from top down (from business capabilities down to physical servers) or bottom up.

If As-Is state is correctly captured, you have a powerful tool in your hands. You know what assets your organization owns, what’s their TCO and what capabilities they deliver. You can do impact analysis and what-if analysis which are great decision making techniques for any CIO out there.

Yeah, and the As-Is state is only fully and correctly captured here:

In reality, most (read all) organizations have no clue what they own. Bigger organizations usually went through several merging and acquisitions where they inherited all the legacy stuff from different companies. Many organizations are federated in its nature, meaning that business units have certain autonomy that they use to buy/build stuff they need. Quite often two business units are buying/building the same stuff, not knowing that other units already have something they can reuse.

So, the reality of As-Is state is more like this:

In reality, you are drowning in the sea of applications, databases, business processes and technology components that you just can’t get grip of. As soon as you collect some information about your underlying assets, they change. You have to go back and ask what has changed so that you can update your As-Is state and so on… in circle… forever…

What most companies do in that case – they just give up! They say, “we can’t update our repository with all the stuff we have out there so we won’t spend any more time on that exercise”.

Fine… but… actually it’s not fine…

I am sure we all know how many TV’s we have in our houses. If we have enough of them, like one per each room, we won’t buy another one right?

Well, why should it be any different to a large organization then? After all, there is your saving potential – just stop buying what you already have!

I guess the true answer lays in the fact that some organizations just have lots of cash and they can afford that kind of behavior.

So, here’s the million-dollar question: “How do you know where you want to be if you don’t know where you are now?”

For those of you who already have millions of dollars, skip the question.

The answer is – you can’t know! You might have an idea where you want to be, but actually to get there would be difficult if you don’t know your starting position. Because the road can be anything between these two:

That brings as to To-Be state. Where do I want my organization to be in 5 years from now?

Again, the simple answer is – you can’t know! Things in this world are just changing too fast!

Changes are fast in IT as well as they are in business. Few years ago we didn’t have smart devices, and now they are the main sales channels. Both IT and business had no idea about it few years ago. So, any of your To-Be states defined few years ago are obsolete by now.

The future will become even faster. You are going to get hit in your face sooner than expected, as we are just at the beginning of the technological revolution. Take a look at the speed of adoption of some things:

With these increases in adoption, it’s very hard to predict To-Be state in 5 years in any domain – business, application, data, technology or security.

So, what do we do now? We gave up on mastering our As-Is state; we don’t know our To-Be state, so how are we going to understand our Transition states? By transition state I mean getting from we-don’t-know-where-we-are to we-don’t-know-where-we-want-to-be.

Should be easy… (good luck with that)

But bear with me; later on I might have few recommendations how to do it…

Let’s continue our journey into unknown by adding one more thing in the whole mix. And that is company politics!

Company politics is when the big guys are doing something to the small guys. The picture explains…

The company politics is that beast that everybody hates, but nobody can do anything about it. Politics is what comes up when you have different cost centers, independent budgets, separate business units and people with big egos. They all have their own agendas and stakeholders to satisfy, so having sympathy for the group level initiatives is very low on their priority list.

I often say that 70% of Enterprise Architect’s time goes on family counseling. Talking to everybody, trying to understand their problems, trying to persuade them that it’s all going to be OK, making them believe that you can be their trusted adviser and so on.

There are several methods that can help you in this family counseling practice.

The most prominent ones are:

1. The Open Group TOGAF standard
2. Zachmann Framework

There are plenty of other frameworks of course.

But all of these frameworks will give you a theoretical idea of what Enterprise Architecture is. They will also teach you a common vocabulary that is used in communication between business and IT. They will tell you that you need to be structured and that all of your artifacts should be organized in an architecture repository. They will teach you how to govern architecture creation and how to review architectures.

But they won’t go beyond descriptive concepts and narratives around them. The practicality and applicability of these frameworks is up to you do define… and that is a problem.

Every organization is different, so basically you need to tailor these methods to fit your organization.

Then the question of tooling comes up. What tools are out there to help  enterprise architects do their job?

Well, mostly MS Office tools. Most of architects use Visio, PowerPoint and Word to document their landscapes, present solution architectures and write architectural specifications.

More sophisticated architects would go for Sparx Enterprise Architect tool that is a great tool for doing solution architecture, but not enterprise architecture in my view. Sparx EA has plugins for all possible frameworks out there (TOGAF, Zachmann, ArchiMate, UPDM, DoDAF, MODAF), it can do business process and capability modelling, heatmaps, roadmaps and some other nice things.

Again in my view, the only true enterprise architecture tool is the one that implements Enterprise Architecture Repository. The following picture shows TOGAF representation of Enterprise Architecture Repository:

Enterprise Architecture Repository is where all of your enterprise assets are stored:

1. architecture relevant documents
2. reference architectures
3. governance processes
4. architecture review products
5. As-Is, To-Be and Transitional states
6. architecture and solution building blocks

It is a place where your artifacts are interlinked together and can show you the world of your enterprise from different viewpoints.

Unfortunately I haven’t seen any tool out there that does that properly. Enterprise Architecture exists more than 30 years as a discipline and still there are no proper tools out there that implement Architecture Repository per the picture shown above.

There are few big players out there:

• Troux
• Alfabet
• Orbus iServer
• Mega

I have tried them and I think that all of them have missed the point of Enterprise Architecture Repository.

First, every enterprise is different. The underlying meta-model must be flexible enough to support customization. But customization without vendor’s intervention. As a client, I need to be able to add/remove/change entities and attributes of the meta-model and I probably need to do that often. None of those tools can support it.

Second, it must be dead simple to use them! User interface of Alfabet for example is just overwhelming. Millions of options, reports, wizards, who knows what else. Architecture Repository is a tool to be used by business, compliance, architects, business analysts, basically anyone in your organization. It is not just for architects. So it needs to be super simple to use.

And last but not the least, pricing! It’s difficult enough to sell Enterprise Architecture practice to the business. Some of these tools have crazy licenses, which makes things even harder for us…

 

By now you either have clearer or even muddier picture of what Enterprise Architecture is. Both results are fine.

Now it’s time to give you some of the advises and recommendations that worked for me…

 

Recommendations

• Get top level management support

Seriously, if you don’t have a full support from your CIO don’t even try doing Enterprise Architecture. Your CIO needs to believe in it so that he/she can defend it. EA practice will get into every corner of your enterprise and not many people will like it. You need to have a strong support if you wanna step on someone’s foot.

• Start building Architecture Repository

Common document storage for your architectural artifacts is a good starting point. That will increase visibility, transparency and possibility for sharing and reusing. For this you can go with some cloud solution – Google Docs or Office 365.

• Lightweight governance

Introduce Architecture Reviews throughout your software development cycle. That will help you validating that the original architecture is actually being implemented.

Start building Reference Architectures for your industry so that you can promote standards and also can have something to govern against.

Governance is all about carrot and stick. You need to give something for people to use so that you have a reason to beat them up if they don’t use it.

 

• Focus on Core IT

What is common in these pictures?

They all use the same roads!

As long as your infrastructure is setup up right, it doesn’t matter what kind of applications you want to run on top of it.

It also works the other way around – you can buy the latest and greatest applications out there, but if you have no means to run them then you just got a Porsche stuck in a mud.

As it is hard to see To-Be state and what business disruptions are around the corner, try to focus on the core IT services that aren’t going to change that frequently. Services that any new application would need, such as: integration (ESB) solutions, document management, workflow solutions, identity management, core financial systems, printing solutions etc.

• Keep it simple and structured
  

Whatever you do, try to do it as simple as possible. It is very easy to create complexity, but it’s damn hard to make things simple.

Try to structure your world. Create a proper repository where you can structure information based on which you are making decisions.

• Have great reports

A right report in a right time is invaluable! Look at your assets and artifacts and try to create as many views as possible out of them.

• Look at what others are doing

There are independent resources out there that can help you in this journey. I can recommend CEB (Corporate Executive Board) that can give you insight into what other companies are doing in the Enterprise Architecture space.

 

That’s all… hope it was useful…