Enterprise Architecture What Everyone Needs to Know

Well, my goal was to put out a post each week, then I thought maybe writing a book would be easier, and as you can tell I accomplished neither. I have now started a YouTube Series on Enterprise Architecture.

I have outlined a series that includes three chapters:

. Chapter 1 contains 5 videos geared to the senior executives. Here I talk about what enterprise architecture is and why every organization needs it.

. Chapter 2, yet to be recorded contains information geared to an enterprise architect and their direct report. Here I talk about the approaches I have used to begin an enterprise architecture practise within an organization. Time and time again I hear enterprise architecture doesn’t work. My first thought is you haven’t seen my approach have you?

.Chapter 3, yet to be designed is going to contain a number of videos geared to various positions within an organization. My thinking is I want to share how every position in the organization is important to the success of enterprise architecture and no only that but how every position can benefit from a mature enterprise architecture practise.

Please have a look at the videos and let me know what you think. Give me ideas of what you would like to see, and how I could improve on what I am doing .

My YouTube Series

Business transformation —- driving change from the business

I have started this post a number of times and kept thinking that this is too obvious of a topic and that I wouldn’t have enough to say but here it goes….

Business operations evolve over time.  New technologies emerge, people become more technically savvy, demands increase, and the world has become more of an online self service society.  ALL businesses/organizations need to keep up with the times.

IT (Information Technology) shouldn’t drive change…  I guess that statement is a little confusing because as I just stated businesses need to evolve to keep up with the changing technologies and society movements.  Maybe a better way to put it is when IT changes technology the reason behind it must be to achieve business goals and objectives.

What is business transformation?

A business is defined by what it does, and not by how it does it.  Transformation is changing how business is done.  This raises an interesting point… what is the difference between operational changes and transformation?

There are a lot of updates and changes that must be made to continue doing what you are currently doing, these type of changes are what I have been referring to as operational changes.   For example changes can be:

  1. a result of efficiencies determined from monitoring applications and processes and measuring against the KPIs (Key Progress Indicators),
  2. in response to policies, rules or regulations changes,
  3. due to security assessments,
  4. technology updates.

Transformation on the other hand is driven by business goals and/or objectives changing and can be triggered by a number of things foe example:

  1. Efficiency… the desire to reduce costs or increase productivity,
  2. Expectations… new leaders, or clients/members demands,
  3. Technologies… upgrades due to decommissioning or advancements and
  4. Amalgamation… combining organizations or departments.

Looking at each trigger independently:


Day to day operations monitor and improve areas in isolation, their goal is to do what they are currently doing as efficiently and effectively as possible.  As staff come and go changes are made and adopted based on assumptions and interpretations.  Applications, systems and processes may not be as efficient when you evaluate the full organization.

An EA has the ability to look at the big picture and identify duplication, overlaps and gaps across the organization.   Looking at the big picture can also identify risks and vulnerabilities that were invisible to any specific area in isolation.


Expectations come from both staff and clients, and have a tendency to change over the years as new leaders come and go, and as new information comes forward.

An EA has the ability to gather and document all expectations, weight them against each other and then evaluate them against the full organization.


As new products emerge IT determines which products do what the business is currently doing most effectively and efficiently.  The problem is what the business is currently doing isn’t necessarily the most effective solution for the business.  If you step back and really understand the business requirements and objectives you will find that some of what the business is currently doing is because of restrictions, misconceptions and assumptions over the years.

An EA never looks at just one element and never assumes the current way of doing things meets the business goals and objectives.  If technology is to be retired, or new purchases to be made an EA must start with the business requirements.  They must evaluate the business goals and objectives to determine the most effective way to achieve the business requirements, they must look for risks and vulnerabilities and they must evaluate based on business resources and priorities.


Acquiring a new company, or merging departments, result in duplicate processes, systems and applications.  Running parallel  is inefficient and choosing one  over the other could impact expectations.

An EA has the ability to step back and look at the big picture. Starting with the business goals and objectives the EA can assess the current environment and put a design in place.   Not only does a merge impact the business processes, systems and applications but it also impacts the corporate processes, systems and applications.


Regardless of the trigger the transformation must start with understanding the business goals and objectives.  There must be a design documenting what is important and what the end goal looks like.  Understanding what you are starting with allows you to create a plan or roadmap ensuring the end goals and expectations are met.

Simply put an EA is used to design change similar to the building architect who is used to design a new house, an addition, or a renovation.  The first step to change must be gathering business requirements, creating a design and detailing out the plan.  It has to be done from an EA position even an IT change

Do organizations need a full time Enterprise Architect position?

In order to answer the question: “Do Organizations need a full time EA position” let’s first discuss what an Enterprise Architect is and what their roles and responsibilities are.

An Enterprise Architect is an individual that analyzes the business and leads an organization through change by designing a future operational model depicting the technology and processes needed to achieve the strategic goals. The Enterprise Architect is the bridge that joins business and IT. 

The EA is responsible for architectural artifacts, standards and reviews that enforce consistency and drive the organization to their business goals and objectives.  Checks and measures are created as a way to determine whether or not the organization is meeting the business goals and objectives once the designs are implemented.  The Enterprise Architect brings forward innovation, risks and at the same time educates the executives.  They ensure business and IT are in alignment and that there is a transparency between the two.

Keys for a successful EA position:

  1. An EA crosses both the business and technical areas of an organization and must report to the CEO to be successful.
  1. An EA does not need to know the business to be successful.  They must have access to the full executive team in order to determine the executive strategic goals and objectives.  It is the executive team that defines objectives, goals and success.
  1. The organization must be ready for change and have a team that supports the people throughout the movement towards the future operating model. 
  1. A transformation governance structure must be in place to facilitate the movement towards the future operating model.

The Enterprise Architect is an essential position to drive an organization to their strategic goals and objectives and to position them to ensure they continue to meet them as they evolve over time.  An EA does not participate in a day to day operational organization, their strength is business transformation.

8 Enterprise Architecture Steps to Business Transformation

I like to think about transformation as the following 8 steps:

  1. Determine the Core Processes
  2. Document the AS IS Architecture
  3. Define Design Principles 
  4. Determine the future business design through User Experiences 
  5. Determine the TO BE Architecture
  6. Create the Transformation Roadmap
  7. Implementation
  8. Monitor and Improve

Within my previous 8 posts I describe how I think about and execute each of these 8 steps.  A successful EA will gage the organization and adjust their techniques accordingly.  The EA does not lead the full transformation, they actually play different roles throughout the transformation journey.

The transformation journey is made up of 3 key sections:

Imagine the possibilities….  Bring it to life….  Realize the benefits 

Imagine the possibilities through design, reach for the stars and then scale it back accordingly.

The EA leads the work in this section, the goal is to translate the Strategic Goals into a Future Operating Model.  

Bring it to life through projects.

The EA assists the work in this section, the goal of the EA is to monitor and ensure alignment across projects resulting in the strategic goals. 

Realize the benefits through KPIs.

The EA builds tools used in this section but does not usually participate.  The goals of the tools are to track the performance of the implementation and ensure the strategic goals are realized and continue to perform throughout the years to come.  This brings up an interesting discussion.  Do organizations need a full time EA position or Architecture office?

The EA position is a powerful and specialized role that is the key to a successful transformation and from my experience is not fully understood.

Completing the TO BE Architecture.

The TO BE Architecture is the overall infrastructure of the organization.  It will lay down standards on how various applications and processes are going to use it.  

Over the years I have run into confusion about what an EA is and does versus the Business, Application, Technical, Data, Information, and Security Architects versus the solution architects.

The EA is focused on the full organization across all disciplines.   They are the link between the business and IT.  They have the ability to work with all levels of management.  They stay at a very high level and connect all components wether it is the people and processes or applications and technology.

The Business, Application, Technical, Data, Information, and Security Architects also focus on the full organization but they specialize in their discipline. A business architect would understand a very high level of the business processes, the org structure and the clients/members, they would be focused on keeping standards and management disciplines in place.  

The Solution Architects focus on one component.  They understand that one component inside and out.  For example they may focus on one application or one core process.  

All levels are equally important and must be able to work together.  Not every organization employs each level and depending on the organization one person may fill many hats.

The EA level TO BE Architecture is a very high level blueprint. The focus is to understand what is important to the business and translate that into a technical infrastructure.  Determining how to get from where we are today to where we want to be in the future starts with identifying the biggest business priorities.  Is it the customer experience, is it the ability to share knowledge, is it attracting new customers and growing the business, is it an amalgamation, is it sales or is it something completely different?

The biggest priorities will drive out the way we evaluate and select the technical A

architecture.  We are trying to determine how we set up the technology we have today to meet the needs of the future.  I am a big believer in reusing as much as possible where it makes sense.

How would we tie our client interactions into one experience?  How would we create knowledge and the ability to find, use, and share it?  How would we increase our client base and scale out the business?  Have we just acquired a new business and are looking at merging multiple systems into one?

Determining the biggest priorities from information we have learned through out the previous steps and then answering questions similar to the examples above will help determine what the backbone of the organization should be.  Once you find possible solutions you will be able to start determining how you should go forward.  You may uncover areas you will not be able to meet or you may think of completely new areas.  You may identify potential risks.

I like to think of more than one possible solution, and build it out with supporting documents. Each possible solution will be supported with things like a list of pros and cons, timelines, and resources.  The goal is to present these possible solutions to the executive team.  They need enough information to make a decision on which solution to go forward with.

A meeting with the full executive team needs to be scheduled to review each possible solution.  I treat this meeting  similar to the ones from the previous posts.  The EA’s job is to get the juices flowing, to present a few possible solutions that will meet all of the facts you have learned to date and then drive out a consensus across the executive team.  The goal of this meeting is to determine the TO BE Architecture, to get buy in and approval.

3 keys to creating a successful transformation journey

Before any “Transformation” work begins you need to address 3 key areas:

  1. Cultural Change
  2. Operations versus Transformation
  3. Design


Change has to include all of the people… I really believe the cultural change has to start happening as soon as you decide you want to change… and I don’t just mean a few emails, presentations, or individual talks.  If you don’t get the proper buy in you won’t be able to plan let alone implement a transformation.

I met one organization that spent 2 years dealing with this before they even started with the hands on business.  They had to show that everyone was dispensable. Staff was let go that did not come on board.  Even key players were dispensable… this sent a solid message.

I worked in an organization that put the blinders on and believed the philosophy “if I build it they will come”.  Well, the problem here is “I build it”. You can’t build this alone and they won’t build it for you.  Projects will spark up under the radar, transformation projects will have “out of scope creep”, and important foundational pieces will be neglected.

I worked in another organization that dealt with people that fought the change by moving them to another area… I have to say, having their negativity still in the organization is more harmful than not moving them at all.  If you are constantly fighting with these individuals, if you continue to spend your time trying to bring them on board you will exhaust and frustrate all of your resources.

People have to feel this is a good, and positive thing… they have to feel that they are secure, needed, appreciated, and included…  This is going to be a hard process in itself and should be the only thing you are dealing with…  I can’t emphasis enough you need ALL of your people on board if you are to be successful.  


Change has to include current operations…

This is huge… it is not like we can just close the doors while we “renovate”. In order to transform you need a lot of your key staff and at the same time in order to keep the doors open you need that same key staff… how do you split these people in half?

I worked in an organization that set up 2 camps… they split their organization into two different spaces.  One dealt with transformation and the other dealt with operations.  They then used a team that coordinated the integration between the two camps.  I have to say this was brilliant and worth doing if you have the resources to pull it off.  The two different camps need different skills… a developer who is successful in operations can’t always succeed in a transformation environment.  The two environments require completely different ways of thinking and working.  Same is true for the business experts.

I worked in another organization that blended the two… the same staff was used to run both streams.  It didn’t work well but I think it could have.  The problem that organization faced was more to do with the cultural attitude versus the actual work.  In this scenario the transformation won’t happen as quickly as the scenario with two separate camps… when staff is pulled to deal with operations, the transformational work will slow and it does take time to come back up to speed once the operational task is complete.

I think the key to this component is the governance structure and portfolio management. It doesn’t matter which route you take, separation versions integration… it matters how you govern the whole situation and how well you are managing the cultural change.


The third area that needs to be addressed is the big picture of your current state or the “AS IS” Architecture.

This really goes back to my previous post.  You have to understand what you have before you can start thinking about changing it.  You need to understand what you are going to be transforming.

I worked in one organization that held brainstorming sessions with staff. They held meetings led by external consultants to gather information about each area of the organization. From my experience sitting around the table doesn’t truly reflect what is happening… things are missed and overlooked.  If you think about it… ask me how I clean my house… I am going to describe what I think I do, what I intend to do, and what I want you to hear but it never really reflects what I actually do. Sometimes there are strange little rituals that evolve over time because of something that is out of your control. These key things may be resolved in a transformation if you know about them. 

I worked in another organization that relied on training material, manuals and other documentation around the organization. The positive about this approach is you are not disrupting operations by pulling staff into meetings however you are going to run into similar misconceptions as the brainstorming sessions. 

Unfortunately I met many organizations that never did create the “AS IS’” Architecture. It is very hard to build a solid detailed roadmap if you don’t have a detailed AS IS Architecture. Integration roadmaps are almost impossible to build without this background. I found the whole transformation to be very chaotic with this approach. The picture was never clear… project scope was happening all the time to compensate for missed pieces. Staff moral was down, they were tired and frustrated as they felt they were always fighting fires. 

I lead an organization through a job shadowing technique I have used many times. I prefer this for many reasons… It does not disrupt operations because you are not pulling staff into meetings, it is the most accurate picture of what is going on, and it allows you to document not only the functions but the information at each step.  I also believe this is the fastest way to gather this information. 

Personally I think this step is missed far too often and if not missed it is not reflecting the full picture. I also believe that not having this information causes a lot of the typical frustrations transformational projects face over and over again. 

I can’t emphasize enough this step is not a waste of time, this information will be used and built upon for your future operating model. I think the takeaway here is business functions do not change over time (yes, they do if your business changes but this discussion is about transforming how you do business ). Business functions evolve… the “how” we do those functions change but the “what” the function is doesn’t change. Your AS IS Architecture becomes your TO BE Architecture by changing how and where you perform those business functions


In conclusion setting up and implementing these three areas takes time, time that is worth it’s weight in gold.   It is not just enough to set these areas up, they have to be positioned in the hierarchy for success. These three areas have to sit at the executive table… they are your executive level during transformation.

If successful they will bring your people through this change. 

If successful they will bring your roadmap to life through projects while keeping operations running.

If successful they will create your future operating model by “balancing and checking” the implementation. 

Seeing as my expertise is EA and not change management nor portfolio management I am going to focus my attention on this third area.  I do think it is important to share information relating to the integration between these other areas but nothing more.