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

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.