Leverage your architecture! Make decisions better, faster, and cheaper (Part 1/3)
Michael Idengren, Agile Architect
Why read this series?
89% of Forrester-surveyed organizations indicate immature or inconsistent use of operational and business data to support strategic decisions, yet CIOs indicate that Business Analysis and Enterprise Architecture are the most in-demand and fastest-growing skill shortages.
Your organization has invested in an Enterprise Architecture / Business Process capability, but it feels "stuck in the mud". You know that EA is supposed to help provide decision-makers information needed to make better decisions, but that doesn't seem to be happening. You want to get more value out of this “EA thing” – that is, you want decision-makers to feel confident getting answers from it. This can be small questions, such as "should we invest in technology XYZ?" or bigger questions, such as "what are our options for modernizing our service"?
This series assumes you already have an EA/BPA platform (i.e., with web portal, flexible method, and tools/advanced scripting APIs) and you have data in the repository. You've got some people who work in the EA area, but you're not sure if you have the right mix of backgrounds and skills needed to define the problem, turn data into information, and provide answers targeted to the right stakeholders. Typical "EA input/modeling", governance, and architecture design/frameworks/theory discussions are out of scope.
Keywords / concepts
Agile EA, EA quality control, quantitative risk assessment, audit readiness, application portfolio rationalization, TIME chart (Tolerate, Invest, Maintain, Eliminate), EA/BPA analysis, EA/BPA service organization, solution architecture options, project portfolio management, EA data vs. information, KPIs (Key Performance Indicators) vs. metrics
PART 1: Opportunity, problem, solution
- Discussion about:
- [x] "EA as a service" based approach
- [x] People
- [ ] Tools
- 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.
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?").
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.
We will discuss three components to a holistic solution:
- A services-based EA/BPA approach. This helps to clarify "what does EA do for me?"
- A flexible EA/BPA/data visualization platform and toolchain. This lets our EA resources produce answers in a fast, repeatable manner.
- 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 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:
So, what kind of people can deliver? Look around! Who is the "Excel wizard"? That person might be a good L2/3 candidate, while someone who is more focused on business problems and simple analysis might be a good L1 candidate. Depending on your organization and staffing practices, it might make sense to outsource L5 developers, but maybe to have one or two in-house L3/4 developers.
The key to effectively staffing an "EA Center of Excellence" includes identification and slotting candidates into the correct level, and supporting them with training and tools. However, unfortunately, it is all too easy to build an ivory tower of architects and analysts who can "do a lot of things", but somehow "don’t show a lot of value" (at least, in the perception of the rest of the organization). Remember that EA groups need challenging and important questions to answer. Using the service-based approach outlined above, paired with executive leadership and interest (the "marketing" part) will define and assign the important "key questions" to answer. Then, the right mix of people and tool capabilities will meet the demand in an agile way.
Continue to PART 2
For questions or to discuss how you can more effectively leverage your Enterprise Architecture capability, please comment below or e-mail the author below.
Michael Idengren, Agile Architect
KPMG CIO Advisory helps your organization deliver EA value in the context of IT/operations efficiency, process improvements, technical solution assessments, and "strategy-to-implementation" digital transformation program governance.
 Forrester's Q3 2016 Global State of Enterprise Architecture and Portfolio Management Online Survey
 Harvey/Nash KPMG CIO 2017 Survey https://home.kpmg.com/xx/en/home/insights/2017/05/harvey-nash-kpmg-cio-survey-2017.html
 Forrester "Defining The EA Service Catalog", April 2017. Alex Cullen and Gordon Barnett.