Business Architect versus Business Analyst

A huge challenge I always run into is the confusion about the difference between the business architect and business analyst. 

I want to start by talking about what they mean to me because they are two very distinct roles and are equally important.

A capability is the ability to do something – they are what is needed to perform business activities and I am not talking about technology!

A capability is broken down into a number of functions and functions relate to “how to do it”.

So going back to the Architect versus the Analyst

An Architect works with capabilities and capabilities must be looked at from a strategic level and not 300+ business requirements.

An architect does not “solution”.  They stay at the strategic level, connect the dots and work very hard to pinpoint what the senior executives are trying to do… the risks they are trying to address, and the advantages they are trying to create. 

An Analyst works with functions within the capability.

The analyst designs the solution, and work in the operational space. The analyst focuses on business requirements and is an expert in a specific silo or area.

Watch this short clip to see an example

Watch the full clip on the Architect versus the Analyst.

My View on the Architectural Discipline that Specializes in Your Biggest Business Asset.

Information is an organizations biggest asset and yet so often it is not treated as such. Information Architecture is the architectural discipline that not only brings efficiencies and reduces informational risks and liabilities but enables Analytics, Artificial Intelligence and Machine Learning. Components that will give insights that create competitive advantages.

The information architect is responsible for architecting the information domain and I want share some of my thoughts and techniques to tackling this space.

Let’s start by exploring what is within the information domain. I look at information from the perspective of three categories: content, data and knowledge.

Content

Unstructured information and includes: files, emails, documents, web content, records, publications…

Data

Structured information and includes fields within tables…

Knowledge

Putting context around information…

It is one thing to have tools so that you can create, protect and use information but that is only the tip of the iceberg for this domain.

Let me back up a bit…

I want to travel back in history to really help get this concept across.

Creating information used to entail sitting down and typing or writing on a piece of paper and then taking it to a record clerk to file it away.

The record clerk would:

  • Create relationships among information,
  • File it so that it could be found,
  • Destroy it when it was no longer needed, and
  • Protect it so that it was only accessed by the appropriate personnel.

When you needed information it involved another trip to the record clerk.

The record clerk was responsible for a number of tasks but it was manageable because it wasn’t as easy to create information not to mention there was only one type, paper.

Travel forward to current day… it is soooo easy to create information and there are so many different types now.

Gone are the days of the record clerk, and in their place technology has been created to replicate the manual steps, for example:

  • Document Management systems were created to manage multiple copies and versions of documents,
  • Record Management systems were created to manage when something needed to be destroyed,
  • Security Classification was created to manage protection levels, who could access what,
  • Search Engines were created to find and access information across multiple storage locations,
  • Archiving technologies were created to improve performance,
  • eDiscovery was created to find relevant and reliable information for litigation,
  • Metadata functionality was created to let systems know what to do with the information,
  • … and the list goes on and on.

There is no way every employee can go through the training of a record clerk, to know which system to use for what, to build the relationships needed between information, and to classify and tag information so that can be filed, found and protected. Even if they could, information has a lifecycle and requires actions to be taken at various stages within that lifecycle. It was much easier for one individual or department to manage because they had their hands on all of it.

As you can see the easier it is to create information the more complex Information Management or IM becomes. The technology that has made it so easy for us to create information has now caused the iceberg below the surface to grow.

Honestly a big part of our problem is we continue to try and manage information using the same paper mentality and use technology to replicate the original manual steps. Information Management is not a “technical thing” and I continue to challenge the traditional IMIT thinking.

I have gone into organizations that say they are paper free but when you look under the hood they are still operating in a paper based environment:

  • They are storing PDFs which are just copies of paper and storing them in file folders.
  • Using naming conventions similar to a filing cabinet so that they can find information.
  • Buying bigger monitors and setting up multiple monitors so they can read through PDFs to find the information.
  • Printing off PDFs that have be scanned into electronic repositories.

Now that you understand how HUGE this area is and some of my thoughts behind the whole issue watch the following clip to understand how I introduce the Information Architect.

This clip is a subset from one of my lessons within the course on How To “Do” EA – Part III. The lesson focuses on how the Information Architect supports the Enterprise Architecture Practice and sets the stage for IM – the ability to manage and monitor information and determine when something is “unhealthy”

Information Architect Clip

Subscribe to get notification for my next post where I discuss the Business Architect versus the Business Analyst.

How Many EA Architectural Disciplines Focus on the Business Side?

In my eyes, there are 3 EA architectural disciplines that focus on the business side of the organization.

The Business Architect is the obvious one, and they focus on people and processes. They are an expert in how to architect the business for success. The business architect is not necessarily an expert in what your business does for example HealthCare, that is the responsibility of the VP of business and their directors and managers. The business architect is an expert in:

  • analyzing organizational structures and business objectives against the current priorities, industry trends and social movements as a few examples,
  • analyzing and reengineering processes at a strategic level across the organization, and
  • identifying potential business risks and underlying issues.

The business architect works with the people within the organization to ensure the business artifacts and in particular the business roadmap is current and relevant.

The second is the Information Architect, and they quite often get consumed with data which is only part of their domain. The information architect is an expert in how to architect business information, knowledge, data, documents, files, records, web content, and email so that it is accessible, reliable, available, consumable, findable and protected. This is such a critical role and in my eyes it is the secret weapon.

The third is the Application Architect, and they traditionally sit in a very technical roll which I continually challenge. The application architect is an expert in how to architect business activities so that they are efficient, auditable, accurate and position the organization for digital transformation.

I have created a 3 part course demonstrating how I “DO” EA from a business perspective… this clip is an excerpt from that course and talks about the 3 business EA team members.

How to Create Well Orchestrated Change!

My last post shared 3 tips for how I start the movement towards well orchestrated change. Today I want to dive in and talk about the approaches I use.

I describe EA as…

Imagine the possibilities through design – I believe you must show value immediately for something to be supported and I do this by creating that first instance of the EA Consolidated Roadmap within a three to four month period. Now I realize there is NO WAY to create a detailed and precise design within four months which is why I start passively. I lead the creation of the MVP (Most Viable Product) or a starting point and then I start participating in “change” to evolve and validate that design.

Make it come alive through projects – I believe you must demonstrate by example for something to be truly understood and I do this by selecting a project to work with… a project to demonstrate what an “EA Influenced Project” looks like. I realize there is NO WAY to walk in and take control of how an organization runs their projects which is why I start passively. I lead the creation of an Architecture Review Board… and I start by running that review board as more of a show and tell. Each meeting focuses on:

  • reusable components,
  • efficiencies that other business areas can take advantage of and
  • a new way of ensuring strategic components and decisions are taken care of.

Which brings me to STAY IN YOUR LANE… I know there are all sorts of architects out there and they range from assorted levels and areas of focus. When I talk about Enterprise Architecture I am talking about the architects that sit at a strategic level. They exist to connect the dots across the organization, they do not specialize in products or systems. These architects focus their attention on ensuring change does not impact the business across the organization. They follow the information flow and business activities across the highest business functions end to end across the organization. They look for patterns across departments searching for ways to bring efficiencies, reduce costs and potential risks and achieve the vision. They must be continuously evolving and testing their thinking against changes being proposed, technology advancements and expectations. They must be willing to put up their hand when contradictions appear.

I have created a three part course… How to “DO” Enterprise Architecture which goes into depth on how I implement the first year of a new EA Practice. I have created a fictitious organization and use it to provide a step by step guide. Watch the following introduction clip… How to “DO” Enterprise Architecture – Using the EA Consolidated Roadmap to Influence Change... to get a preview of the course which is due to release December 2020.

EA does not happen overnight – tips to help year one

I have said many times that what EA means to me is well orchestrated change… the ability to create a design for the future and work within the current environment through well orchestrated change to realize the vision.

The fact is this is not something that will happen overnight.  One of my favorite sayings is changing an organization is like turning the titanic with a wooden spoon… and some days it feels like the wooden spoon is being eaten by fish.

I want to share three of my techniques for helping an EA Practice in it’s first year…

  1. Start passively – year one is all about “influencing change” … listening, observing, validating the design, and planting seeds.
  2. Educate through example – pick one project, and run it as an EA influenced project to show the benefits and value,
  3. Stay in your lane – think strategically by connecting the dots to ensure:
    •  information flow is not being impacted across the organization,
    • reusable components are used across business areas and departments and
    • priorities and dependencies across all 5 architectural disciplines are not overlooked.

The job of the EA Practice is to create a design and be armed with a million ideas for how to implement it and be able to pivot the thinking based on the environment, priorities and discussions at hand.

Excited to Announce…

How to Create an Enterprise Practice Roadmap course is being recognized as the highest rated on Udemy!

Please keep the suggestions coming so that together we can keep it at it’s best.

This course contains four sections, each section walks you through the steps I take to create a roadmap for an Enterprise Architecture Practice. The roadmap is a list of activities that need to transpire to move an organization from a level 0 to 5 EA maturity.

Similar to creating an EA Consolidated Roadmap for an organization you must start with an understanding of the vision for the EA Practice. Ideally all organizations should have a vision to achieve a level 5 maturity but not all leaders are willing to invest in something they do not completely understanding.

My approach is to educate the organization while gaging the maturity level with a goal to have the senior executives asking… “What is the appropriate Enterprise Architecture Practice for our organization?” and not “Do we need an Enterprise Architecture Practice?”

The course focuses on the 5 areas measured when gaging an organization’s EA Maturity level:

  1. EA Process and Activities – the tasks performed by the EA Team. EA is all about orchestrated change and it is the EA process and activities that put structure around organizational change. Having structure around change ensures potential risks and liabilities are addressed and that projects achieve business goals and objectives.
  2. EA Team – consists of five architectural disciplines lead by the Enterprise Architect. Each architectural discipline ensures their area of expertise is considered at all times. The leader of the EA team bridges the gap between business and technical.
  3. Governance – vehicle to manage organizational change.
  4. Business Processes – are what the organization does. Having a level 5 EA Maturity means all business processes are managed and monitored using KPIs (Key Performance Indicators) and change is based on metrics of how well each of the business processes is performing.
  5. Organizational Commitment – Enterprise Architecture must be embedded within the full organization for it to be successful if there is not a commitment from the full organization a level 5 maturity will never be realized.

The course starts with walking you through the steps to understand the senior executive’s vision with respect to an EA Practice. Once the vision is understood the course will explain how to gage the organization’s current EA Maturity Level. By analyzing the current state and discussing what I have learned throughout my career I will help you identify the activities needed to move your organization from a level 0 maturity to a level 5.

EA – How to identify an organization’s vision and direction

Enterprise Architecture is about creating orchestrated change.  Understanding the vision and then designing a plan for how to move the organization from the current state to the future is one of the main objectives of an Enterprise Architect.

 The only way to do this is to understand the senior executive teams’ visions, priorities, and appetite for change.  Senior executives are the ones accountable and liable for the organization and for this “change” to be successful there must be one clear vision and direction endorsed by the FULL senior executive team. 

Time and time again I am asked… How do you get the senior executive team to land on one clear direction and more importantly how and what do you get them to prioritize?  My response to questions like those is… How much time do you have?

Every organization is different, and the answers depend on the environment and the people within it, there is no way to just give one answer to those questions.  What I can do is walk you through the process that I take to come up with the answers and along the way explain some of the hurdles I have run into.

I land on the vision by focussing on:

  • what the business of the organization is and what it should be,
  • the systems, both processes and applications within the organization and are they following industry best practices,
  • the strategic areas of change and what they mean to operations and
  • each of the individual senior executives’ thoughts and goals. 

I bring the full senior executive team together and challenge them on aspects of the four focus areas mentioned above, we explore status quo versus eutopia type scenarios.  Taking this approach will get discussions going and will lead to the best decision for the full organization with the one leader typically the CEO making the final decision.

I land on a prioritization by focussing on:

  • business capabilities or the functionality it takes to perform the business activities and
  • potential risks which includes such things as manual errors, inefficiencies, data integrity, safety, reputational and litigation to name just some.

Knowing that priorities must be driven from a risk, liability, compliance, value add and modernization perspective I apply potential risks to business capabilities. I then present them to the full senior executive team during a prioritization exercise where we explore what was observed during job shadowing sessions.

For a step by step guide demonstrating my approach using a fictitious organization – How to “DO” Enterprise Architecture – Part I – Creating the Consolidated Roadmap.

Architecture – A core part of strategic planning that is so often overlooked.

I think my ultimate goal is to change the way organizations look at and think about Enterprise Architecture. My thinking is if we “Architects” and Enterprise Architects in particular start moving the shift from a very technical to a business way of doing things we won’t have the C-Level executives glaze over when we start talking.

The Enterprise Architect has to be at the strategic planning table, and architecture has to be a core component to strategic planning.

I would love to hear your thoughts on this topic…

I want to help…

I have spent the last 30 years working in the IMIT field and I want to share my experience to help organizations during this uncertain time. My worry is that due to this social distancing it is almost impossible to bring experts in so we must come together and use the resources we have.

During this time it is the strategic resources that can help executives come up with a plan. A plan that will not only help them continue their services but help repurpose their staff so that they are not adding to this economic crisis.

Last week I put out a video showing how Business Architecture can help, and today I am offering my services free of charge. Please reach out if you would like to chat and learn more in addition to that I am creating a package to show step by step how to unleash the power of business Architecture and will make it available free of charge in the coming weeks.

My hope is some good can come out of this crisis…

Enterprise Architecture 101 for Executives… What Every Executive Needs to Know About EA!

I have created 5 short clips to explain Enterprise Architecture that every executive needs to see.

I start with a brief introduction…

Then I share my thoughts on what an Enterprise Architect is and the characteristics that make them successful…

Next I describe the process behind Enterprise Architecture and the keys to it’s success…

Now understand why EVERY organization needs EA…

The last piece of the puzzle is to understand the Architecture Team…

Watch for a course on how to assess the maturity of the Enterprise Architecture Practise within your organization…