EA - Radio - Episode 6 - Where do I start EA? - Part 1

Welcome to the Enterprise Architecture Radio. For the last couple of episodes we have been discussing how enterprise architecture can drive value and help an organization become more agile. We talked about disruptive transformative innovation and we also talked about small evolutionary innovations that keeps the organization agile, nimble and operationally efficient.

​

But let's say that you are an enterprise architect or a part of an enterprise architecture team. How do you get started doing all these innovations? And it is a daunting task. Maybe the organization has been around for decades. And if you are thinking about enterprise architecture, in all probability you are associated to a considerably large and complex organization. Because EA is an expensive endeavour. So you wouldn't consider it if you don't really really need it. And if it has been around for a few decades, its possible that it has gone through multiple mergers and acquisitions, launched many products and services, and spread across multiple geographies.

​

There are so many business functions, so many processes, so many internal services and then there are applications some SaaS, others hosted on the public cloud or some probably on On-Premise data centres. And then data. Don't even get me started about the data. There is so much data. And there is so much diversity in the data. And the EA team has been given the task of making sense of all this. Give a big picture about everything and pull out business intelligence that will help the leadership and drive value in some way. 

​

Every organization has its own reasons why an EA is required. The first question that we must ask is Why do we need EA? And this is not a generic question. We already covered that generic question in the first episode itself. This is a very specific question pertaining to the organization the EA is associated to. And every organization has a very unique reason why they are considering EA.

For example its possible that the organization has gone through multiple mergers / acquisitions / divestiture and their entire landscape is now murky with diverse people, functions, systems, processes, services, all coming together. It is all very jumbled up and they want to untangle their landscape.

 

Other reasons could be that the organization has seen a game changing innovation that they would like to leverage, but the entire proposition involves a large transformation of some sort, perhaps a re-org or shutting down a few existing lines of business

​

Or it could be a simple matter of looking at existing inefficiencies, gaps, redundancies and making the organization leaner and more focused.

​

Although truth be told, in my last 13 years as an enterprise architect, I have never seen that one as a reason for the leadership to invest in an EA capability. Can't blame a guy to be hopeful though...

Because unless we understand the very reason why the EA is required, we cannot deliver value. And the first purpose of EA is to make it sustainable. To help organizational stakeholders to understand that EA does drive value and the investment they are making will generate good ROI. The idea is to attack a few low hanging fruits and deliver value quickly so that the leadership is confident that this is a good move forward. And then from there on, start working towards the maturity of the EA Capability that you have established.

​

This activity, though, is easier said than done. First of all EA is a top down approach. Unless, at least some of the leadership team members understand that there is a need for EA. Unless they are the ones requesting it, it is not possible for the EA capability to get established and mature. Because to understand the context, the EA team will have to sit down with the leadership to talk about what their objectives are. And the leadership must give them not just the resources required, but their time as well.

​

Yeah, EA is a politically sensitive activity. You will be constantly working with the leadership, balancing their conflicting interests and that requires some serious soft skills. But we'll talk about that later.

​

Once you have firmly established the context of why you are doing enterprise architecture, the preparatory activities begin. We start with the big ticket items. There are three points we must prepare for. 

​

Budget and resources, An architecture board and A governance function. 

​

First is point is budget and resource. Usually an enterprise architecture capability's need arises from the top. If the leadership thinks that an EA is required budget should not be a problem. Sure it may not be a million dollars to begin with, but you should have a budget to get started. How much and for how long are discussions required based on the initial scope and context. Among resources you will require people with the right skills and tooling. There are some specific skills required for running a capable enterprise architecture team. 

​

First of all, some generic skills. And these are usually most underestimated like leadership skills, teamwork, interpersonal and communication skills. 

​

Then you have  business skills like strategic planning, understanding business processes, etc. 

Of course you are going to need people who know design. And that includes application design, database design, role design, system integration design and be able to build design models. You would need project management skills, and IT Service Management skills like incident management, change management, problem management, etc. 

​

A software engineers with experience in programming software, database administration, and information security. And infrastructure engineers with some on-premise and some public cloud experience.

​

And finally some legal skills like data protection laws, contract laws, procurement law, fraud, etc.

Of course not all these skills are mandatory and of course you may not need people to be proficient in every skills. You may also have some of these as transferrable skills or subsidiary skills. Like a project manager who has some experience in projects dealing with contract / procurement law. Or a software engineer who has worked on a major database or project. You pick and choose which are the most important skills you need at the moment based on the enterprise architecture context and of course how much budget you think you can pull.

​

That's budget and resources. Now let's talk about the second point which is setting up an architecture board. The primary responsibility of the architecture board is to make sure the EA process is evangelized, followed and improved over time. Also they need to take the responsibility of approving all exceptions from the standards. The board will have members who will have responsibility for their own domain. This could be business domains like specific lines of businesses, or it could be technical domains like database architect, cloud architect or security architect. Each member will have authority over their subject of expertise and will take decisions around standards and exceptions. 

​

And under budget and resources point there is one more resource, which is tools. There are a number of very interesting enterprise architecture tools that you can that make your work very efficient. They have capabilities to sync up with your ITSM and CMDB and pull in live data on a weekly / daily basis and they have beautiful reporting and dashboarding capabilities. The Gartner Magic quadrant for EA Tools, lists out the top tools in the industry, but It would be prudent to run a PoC on a number of tools before you decide which tool to pick. If you have decided on an EA Framework you are going to use, then there are tools certifications. Like there is a TOGAF tools certification program where they certify the tool that implement the TOGAF framework.

​

Which brings us to the third point. Setting up a governance function. Human beings are lazy and if we leave it to them, they will not follow any standards, they will just keep taking convenient shortcuts and do what's easiest. That's why organizations without an EA function or at least some big picture view team or role, fall into chaos. So governance is required and right at the beginning. A clear message needs to be sent out about the governance function. Now does that mean this will be an Omnipotent, all powerful, my way or the highway type governance function? Not necessarily. It could align with already existing governance function like legal and compliance, software compliance, etc. And bring everything under one umbrella. There are all powerful versions of governance as well, but then there are governance functions that work on the buy-in model too. Where the governance team educates all teams about the standards and helps them understand why the standard needs to be followed and hopes that they follow. How we setup the governance function will depend on the culture and the environment of the organization. However a governance function needs to be setup and a clear message needs to be sent out to all impacted stakeholders about how it will function, before any EA work begins.

​

After these three important points are taken care of there are a few more things such as picking the right EA Framework, understanding how mature you are as an EA Capability or understanding the organizations maturity level when it comes to any big transformation or how to choose your first project and so on. But that's all the time I have on this episode. So we will cover those in our next. So watch out for the next episodes.