Leverage your architecture! Make decisions better, faster, and cheaper (Part 1/3)

Contents

PART 1:  Opportunity, problem, solution

• Discussion about: 
  • [x] "EA as a service" based approach
  • [x] People
  • [  ] Tools
• For:
  
  • CIO / CTO
  • Strategic Portfolio Managers
  • Project / Program managers
  • EA program manager
  • EA Architects
  • EA Analysts
  • IT DevOps managers

PART 2:  Actually making it work:  People & tools

PART 3:  Case study:  System rationalization in controls readiness context

Articles will be posted each week, so come back soon for more details!

PART 1:  Opportunity, problem, solution

You've taken the plunge, and invested in an Enterprise Architecture (EA) / Business Process Analysis (BPA) platform to centrally maintain lots of content (processes, apps, data, infrastructure, etc.).  You've got a governed method and standards for maintenance of the repository content (i.e., TOGAF, Zachman, DoDAF).  This situation presents an opportunity, a problem, and a solution.

The opportunity

Eventually, someone is going to ask questions ("business problems"), which can be answered using a slice of architecture data.  The trick is to simplify ("flatten") the EA data into "information", to help make decisions.  This can help answer typical (smaller-scope) process analysis questions, such as as-is vs. to-be process differences.  For a "medium complexity" application portfolio rationalization effort, it can be used to decide which systems to keep or retire.  It can also be aligned towards industry/functional specific questions, such as "Why do we continue to have poor audit findings?  Which systems are the biggest factors?" (Our Part 3 case study is based on this scenario).

The most mature use of EA will accommodate answering complex end-to-end solution analysis.  We might want to boil complex options to simple questions, such as "what are the costs, benefits, and risks of solution A vs. solution B?"  For example, in an emerging technology example -Blockchain- a scenario comparison quickly compares various solution derivatives to each other, focusing on using technology to improve key areas balancing risk, cost, and benefits.  This might result in a decision to do "a little bit" of Blockchain up front, paired with a longer-term API/integration on-premise/cloud investment strategy.

We work with business stakeholders to describe high-value "key questions", and assemble data (i.e., processes, capabilities, systems) into "architecture views" needed to provide the desired information.  We will typically need to gather new data, or cleanse existing EA repository data.  Depending on the scenario, it could be a "big question" or a "small question".  Small questions might result in a small effort to produce a report, while larger questions could involve efforts like capability/process/system rationalization and alignment (the bulk of which is typically working with business stakeholders to agree on terminology and levels of detail!)

Those business stakeholders might want that information in the form of a simple report (e.g., in PDF or Excel formats), perhaps e-mailed daily or weekly.  Or, it might be more appropriate to provide a real-time dashboard view, depending on the complexity of the data and how "summarized" it needs to be.  This might be a longer-term monitoring question (e.g., "We projected a 20% reduction in time needed to maintain these systems, so what's the monthly status of our KPI readouts?").
 

The problem

Now, we turn to answering the question – the EA repository has a lot of "stuff" (raw content), in a multi-level, inter-connected hierarchy (architecture), that people don't really understand (except maybe a few architects), and even fewer people know how to mine (i.e., JavaScript or SQL developers who are familiar with relevant EA methods and tool APIs). 

During the "opportunity" phase, we worked with key stakeholders who have business problems (questions) to be answered. After we helped to narrow down "the right" question, and collected/scrubbed data needed, we might have to scramble to find resources to provide an answer (in a way that is easy to understand).  This turns into a mini-project, which takes time and specialized resources.

The solution

We will discuss three components to a holistic solution:

1. A services-based EA/BPA approach.  This helps to clarify "what does EA do for me?"
2. A flexible EA/BPA/data visualization platform and toolchain.  This lets our EA resources produce answers in a fast, repeatable manner.
3. A staffing/enablement model to define and answer questions at a low cost

Services approach.  We divide the work done to "answer the question" into a continuum of services:

Each of the services has enabling assets, tools, governance, consumers, and producers.  From the "end consumer" perspective (the stakeholder who wants to make a decision), most will only care about the end result – the "present" deliverable (i.e., dashboard or emailed report).  However, intermediate analysts (i.e., IT, Line-of-Business, or project-focused analyst) might want a quick answer to their problem (the "flatten" service, asking "just give me the spreadsheet").  Some might want a report in their inbox weekly, a link to a dashboard, or just a single, one-time attached report.  For the most part, none of them will want to hear about "enterprise architecture" or "BPM/BPA". They just want their questions answered.

Taking a service-based approach allows the EA/BPA group to clearly show value (and, in mature organizations, commitment via service level agreements) to the services they provide to the enterprise.  Of course, a successful service model requires more than just presentation slides or boxes on a screen; it needs a "marketing" campaign (to get "internal" customers who will ask the key questions), reliable technology, and people who can deliver.  Using an incremental approach, such a model can "start small", show successes, gain credibility, and scale.

The simple "answer a question" context services listed here are intended for "non-EA" analysts and business stakeholders with specific questions.  As an EA organization matures through visible contribution and credibility, Line-of-Business and IT leaders will continue to "ask for more".  When an EA organization reaches a certain point of maturity, it makes sense to create an EA service catalog[3] to leverage an "outside-in" approach; that is, primarily focus on what the business needs, and align EA services to deliver value.  This "outside-in" concept can be expanded to more encompassing EA services, such as technology/target state solution service, or a business/technology portfolio review service.

Service enablement:  Technology.  For reliable service delivery, a base platform of EA technology/infrastructure needs to be in place.  It needs to have sufficient capabilities in method customization and "app development" capabilities, including relevant APIs for interfacing and reporting.  Most of the development is typically ETL-oriented  (Extract, Transform, Load).

Service enablement:  People.   After defining the services and technology, let’s have a look at the last, and most important ingredient needed to make things happen – the people.  Not everyone has to be a programmer - some analysis questions are simple, and can be answered using typical Out-Of-Box (OOB) tools, such as reports.  Fewer people are needed to do more complex development work; factors include EA integration environment complexity/maturity (higher complexity might mean more L3-L5 "scripters/developers", as described below), and EA tool "OOB capabilities (higher tool capability might mean fewer L3-L5 "scripters/developers" needed).  Generally speaking, an organization will need more analysts, who are closer to the business problems, and fewer developers.

Here is a typical analysis roles profile, where "more analysts" and "fewer technical developers" are needed: