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.