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.

Published by

Lisa Pantuso

Lisa Pantuso is passionate about business transformation. She has worked with corporate leaders and executives over the past 30-years making their visions and strategies come to life. Having worked across Finance, Health, Justice, Social, Natural Resource and IT industries Lisa is qualified to help your organization. Lisa is known for creating results and "doing it right", sought after for her ability to lead and engage the full organization through change.