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

The difference between Enterprise Architects and Solution Architects

In my opinion there is confusion around the architect positions.  I have seen some strange position titles with the word “architect” in them.  The way I like to explain the whole concept is by comparing organization architects to building architects.  The building architect’s main  focus is the design and integrity of a building whereas the organization architect’s main focus is the design and integrity of the whole operation.  There are 3 architectural levels as follows:

1. Building Architect – The role of a building architect is to understand the strategic goals and objectives of the building and create a design working within the city’s policies and standards.  This is true wether the design is a renovation, addition or a new build.  The end result is a blue print.

A building architect is not an electrician nor plumber and does not get into the wiring nor plumbing details but does have an appreciation of the trades and can highlight certain requirements.  Once the main blue print is created an electrician will take a copy and start over laying their designs, and a plumber will do the same thing.

2. Discipline Architects – Electricians and plumbers are examples of disciplines.  The role of an electrician for example is to understand the building codes that apply to electrical, add their design to the blue print, have the implementation inspected to ensure compliancy and coordinate with experts related to specialty electrical systems.  

For example the head electrician will direct staff to drill the holes and pull the wires implementing the design, schedule an inspector to ensure compliancy and coordinate with a home theatre specialist.

An electrician is not an expert in all of the different electrical systems. They will reach out to solution experts in this case the home theatre specialist to detail the designs for a home theatre system.  The electrician will coordinate among all of the electrical system experts.

3. Solution Architects – The home theatre specialist is an example of a solution architect.  They know their system inside and out, their sole focus is that one system.

Going back to the organization architects you will notice a similar pattern.

1. Enterprise Architect – The role of the enterprise architect is to understand the strategic goals and objectives of the organization and create a design.  The end result is a “TO BE Architecture” or Future Operating Model.  For more details around the role and responsibilities of an EA refer to my previous post.

2. Discipline Architects – The discipline architects focus on designs and standards within their area of discipline.  Their role is to work with the EA to understand the TO BE Architecture (similar to the blue print) and to over lay the details of their discipline.  They will create standards (similar to the building codes in the example above) to ensure consistency, reviews (similar to inspections in the example above) to ensure compliance and  create measures and tools as a way to monitor the day to day operations ensuring strategic goals continue to be met.  Looking at each discipline independently:

    1. The business architect is all about the user/customer/client experience, and efficient business processes.  The tools and measures center around KPIs (Key Progress Indicators).  The business process manager and business analyst are examples of roles that would use the measures and tools to ensure day to day operations continue to meet the goals.
    1. The data and information architects as their name states focus on data and information.  The difference between the two is the data architect usually focuses more within the database and the information architect deals with the bigger picture of enterprise content of which data is just one part.  This discipline works very closely with the business architect.  They must understand how information relates to the business, and how it is used within the processes so they can create standards around how to find, store, use, share and secure the data and information.
    1. The integration and application architects focus on software.  The difference between the two is the integration architect usually focuses more with the in’s and out’s of the different systems and how they communicate with each other.  The application architect deals with the bigger picture and focuses on the systems and functions including integration.  This discipline works with the business and information architects to understand how the functions relate to the business processes. They create standards ensuring applications are decommissioned to avoid duplication, upgrades happen to avoid unsupported software, and functions are efficient and shared across systems to avoid duplications and inconsistency.
    1. The technical and infrastructure architects focus on hardware.  They create standards related to the network, servers, and routers as a few examples.
    1. The security architect works closely with each of the other 4 disciplines adding the security components and standards.  They also create measures and tools to assist with risk assessments and security breaches.   

3. The solution architects – The solution architects are focused on individual areas or systems within an organization.  Each of the 5 disciplines have a number of solution architects to help detail out the specific pieces within their domain.  They are responsible for the designs, standards and measures related to their system.

In summary an architect does not implement nor run the day to day business, they create: 

  1. designs so everyone knows what they are working towards, 
  2. standards and guidelines to ensure consistency across the organization during implementation,
  3. reviews to ensure compliancy and
  4. measures and tools to ensure production is meeting the organizations goals and objectives. 

The difference between the Enterprise Architect and Solution Architect is the area of focus and the level of detail.

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.

Documenting you AS IS Achitecture


There are 5 Architecture streams to consider:

  1. Business
  2. Application
  3. Security
  4. Information
  5. Technical

Getting your “AS IS” in each of these streams is important but they do have different weights of importance for this piece of the puzzle.

I am going to start with the business architecture.  The first thing I like to get a grasp of is identifying the core business processes and the core corporate processes.  There are many ways to identify these but the important factor is to identify them and get buy in from the organization.  These have to be high level and there shouldn’t be more than 10 of each type (business and corporate).  One of the ways I like to think about them is to go back to the old mainframe way of thinking.  What would that first main menu have on it?  The menu that leads the staff into each of the business areas.

Once you come up with this list and get approval from the executive team you have the start of your AS IS  Business Architecture. 

This may sound corny but I like to have the core business processes printed out and laminated… this list is going to drive everything and it is so important that everyone in the organization knows what they are and starts talking about them.

For each of these core processes you need to create a process flow diagram.  Please stay out of the details the only things we are interested in are the functions, information/data, whether or not the function is manual or auto, and a high level of the ins and outs.  

My preference to gather this information is to send the business and information architects together to job shadow.  They are to sit behind the operational staff and follow the core process through the organization, this could mean sitting with different people.  I really drive this through the process from start to finish regardless of the divisions within the organization.

At the same time the Application Architect is gathering a list of functions from an application perspective.  This may sound daunting but it needs to be gathered from a very high level.  We need to understand basically what each application is doing.  

Once the business and information architects have entered their details into the diagram the business and application architects map the business functions to the application functions.  All manual functions must also be identified, they are just as important as the automated ones. 

I don’t believe in the Architects working in isolation here.  It is very important that this foundational information is accurate, if they need to set up meetings with SMEs (Subject Matter Experts)  by all means encourage it.  Don’t lose details about the manual functions as these could be identified as a potential risk and a high priority transformation element.

I can’t stress enough how important buy in is… all of these processes must be reviewed and approved by more than just the architecture team. Not only are you ensuring accuracy you are getting that very important buy in as well. 

Once the core processes are documented I want to understand the KPIs… Key Performance Indicators and I want to know this from an executive level.  The CFO will have a very different answer from the CIO and each is very important when it comes to transformation.  I need help from the CEO to weigh these.  The results from this step are going to help drive the design of the “TO BE” Architecture. Not only are these going to help build a way to manage the process in the future these indicators are going to tell me what is important to the executives.  Architects are not business experts nor do they need to be.  They need to be able to pull that information from the organization and ensure the end results meet the organizations goals.

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 for this discussion we are talking about business transformation). Business functions evolve… the “how” we do those functions change but the “what” the function is doesn’t change.

I haven’t really talked about the security or technical architectures… these are important but most organizations I have worked with if not all have documentation with enough detail for this piece of the puzzle.  These two streams are the pieces that will really change/evolve.

The artifacts from this discussion is your AS IS Architecture.   There are many applications that can capture this type of information.  At this point I am not going to get into those discussions.  I would like to create a future post dedicated to just that topic.