Bob Ivkovic, Principal of IT Architects
August 23, 2018
In News Release #1, the focus was to explain what Service-as-a-Architecture (AaaS) was, and what it was
NOT. There is a lot of confusion as to what AaaS is, and if you conduct a survey with ten IT professionals, chances are that you’ll get ten different answers, unless of course they’re all architects working for the same company. The following describes 3 key characteristics of AaaS. I’m sure some senior architects may debate these characteristics, but let’s consider and mull them over before we take this to court.
3 Key Characteristics of AaaS
There are three key characteristics that qualify IT architecture as Architecture-as-a-Service (AaaS) as described below.
1. AaaS is typically an outsourced service provided by architecture experts
AaaS is a complete package of architecture deliverables along with the services to be provided by an external vendor, usually a consulting firm specializing in business and IT architecture. There’s no rule saying that AaaS cannot be part of an organization’s internal architecture practice. Regardless, whoever it is, they bring in the resources, templates, tools, architectural metrics & KPIs, and even the business & IT value propositions. They also bring in the experts to execute the services required to build the architecture foundation or deploy an IT solution. This is all decided up front and the client isn’t responsible for the architecture delivery except for providing business & IT input demanded by the vendor and signing off on the architecture deliverables once the contractual obligations have been met by the outsourced party.
Let me give you a quick example where I was engaged to lead an architecture governance process for a large-scale ERP implementation for the government. The government required a data architecture of it’s current state in order to understand how its data would be consolidated to support its future-state common business processes. The problem was that the government didn’t have the people, tools, methods, nor expertise to attempt what seemed to be an impossible feat. Thus, they hired a reputable consulting firm that would bring in experienced data architects, the architecture repository and modeling tools, the architecture methodology, the governance processes, and everything else that was required to get the job done. Actually, a lot of the work took place at the consulting firm’s offices because the client didn’t have enough cubicles and meeting rooms to accommodate the vast work effort. This was in fact what I call “extreme outsourcing” because the client couldn’t deal with the delivery scope and the number of people to complete the work effort (both internal and external). By the way, this initiative was also too big not to have an enterprise architecture repository to store all the artifacts and manage all the relationships and dependencies between the business processes and system functions and data. There was also a ton of metadata that needed to be captured to describe each artifact. The vendor not only had to provide the enterprise architecture tool but 6 all the standards and governance that go with it. Besides, the client wasn’t about to spend $7K per license for a tool they didn’t know how to use, nor did they have the right people to learn it. The client relied on the vendor to provide the modeling and tool experts, and the architects that were going to get the initiative over the finish line.
As a qualified vendor specializing in AaaS, it is responsible for bringing in the tools, methodologies, governance processes, deliverable templates, scope calculators, metric/KPI benchmarks, quality standards, and the list goes on. This vendor works with the client to ensure that the architecture deliverables meet the objectives of the engagement and achieve the architecture outcomes expected by management. AaaS, done properly, ensures you’re getting a
hot pizza with all the pepperonis to satisfy your palate. Why do you think big organizations hire Deloitte, Accenture, E&Y, PWC, and some of the other big boys? They provide the architecture know-how, while the client is responsible for providing the organizational know-how to make it all happen. And if the vendor doesn’t, penalties and interest are calculated and deducted from the bill. It kind of reminds me of the government when I don’t submit my tax return on time.
2. Architecture services are based on generally-accepted industry architecture principles, standards and benchmarks (which are defined in the contract before services are rendered)
Think of it as a service level agreement, but in this case, it’s an architecture delivery and compliance agreement. The delivered architecture solution has to comply with an architecture standard for architecture, such as TOGAF, EA Framework, Zachman, IEEE, DevOps, MDA, and so on. There are also productivity and quality benchmarks with performance measures & metrics for business processes (such as financial, manufacturing, logistical, etc.) in various industries. I’m a big fan of process performance metrics and industry benchmarks provided by outfits like APQC. This allows organizations to compare performance requirements against those of companies in the same industry. Furthermore, this allows organizations to gain information on philosophies, practices, and measures that will help them take action to improve their performance. Thus, when you do go out to market for architecture services, you’ll tell them what you want and you won’t pay for it unless it meets an architectural standard. This takes me back to the pizza delivery analogy. If you order a pizza from the nearby pizza joint, and if it doesn’t come with the custom ingredients you asked for, expect to be eating a pizza that you didn’t ask for. Or even worse, what if the pizza takes 45 minutes to deliver and is cold by the time the doorbell rings. The problem with both of these scenarios is that the end benefit wasn’t delivered according to a standard (i.e. with all ingredients, and within 25 minutes based on location). There is a pizza delivery standard practice that has to meet at least two criteria: 1) The pizza has to be hot upon delivery, and 2) The pizza has to be the one you ordered on the menu, with the modifications specified (e.g. extras, half & half, special order). Eating the wrong pizza, or serving your guests a pizza that tastes like leftover pizza, is a failed service. This is why we have predefined industry standards and benchmarks, even in the pizza business. So, when I say “predefined” I mean the organization is going to get the results that they expected and signed off on because the vendor has promised to put the right people (architects) on the job to deliver the right deliverables to their satisfaction. I remember an organization implementing a cloud SAP solution where the business demanded to transform all batch interfaces to real-time. AaaS provided pre-packaged SAP PO interface design specs for core interfaces with built-in error-handling and recovery (which represented 85% of the organizations interfaces), while the other 15% were based on custom integration specs outside of AaaS (by engaging top-notch integration architects specializing in SAP PO). At the end, the right interfaces were delivered because the vendor understood the architecture services required to meet all integration requirements.
3. AaaS provides the architecture services to transition from strategy to tactical to operational deployment (and abstracts these architecture layers as part of its architecture services)
AaaS is based on a 3-tier architecture service model that allows an organization to develop a strategic understanding of its IT architecture direction, which is then transformed into a tactical game plan required to deliver according to the architecture strategy, which in turn is transformed into an operational architecture deployment. Let me give you a real life example. I was called by a colleague and the chief enterprise architect of an organization who was requested to develop architecture blueprints that would demonstrate to management how a proposed integration solution could be taken from a strategic to tactical to operational level of abstraction (i.e. 3-tier architecture). The caveat was to transform these tiers of abstraction by relating artifacts from the strategic tier down to the operational software/hardware components (with the tactical tier being in the middle). This was up my alley since I’ve been
using a 3-tier architecture service model for decades to help organizations define their integration landscapes. We met at a nearby Starbucks and I basically sketched three model representations (with artifact connections) in a notebook he brought along (by the way, that notebook and pen saved us from what would have been another architecture dilemma without it):
1. Strategic Architecture Tier – This was simply a collection of business processes with relationships across functional areas of business. I assigned strategic drivers to each process such as goals/objectives (by business area) in the annual report, business & IT KPIs, industry metrics provided by industry reference models (such as those found in APQC), and so on. These comprised the metadata for each business process. Related business processes were collected and stringed together into an end-to-end business process flow.
2. Tactical Architecture Tier – The end-to-end business process flows were replaced with a system function (since the process flow would be automated by system functions). I made the system functions big so that I could list all the supporting IT components inside each one (including COTS systems, bolt-on & add-on software, workflow & complex event processing products, database repositories & data aggregators, etc) that would automate each business process in the flow. I also drew the lines between the processes to identify what interface touchpoints would be required and what data would flow between these processes.
3. Operational Architecture Tier – I attached the specific software solutions (both current and future systems being considered) to each function, what kind of interfaces would be required (point-to-point, publish/subscribe, ETL, etc), and innovative solutions that were required to provide workflow, mobility, real-time data aggregation in the form of an Operational Data Store, data analytics, etc. We even talked about leveraging specific technologies they had in-house like TIBCO integration broker, Appian workflow, and Oracle Data Warehouse. Don’t worry, leading cloud and mobility software products were also a part of this conversation.
There it was – an abstraction of strategy, tactical deployment, and operational applications and technology (supported by the strategy). This is what I mean by AaaS having the capability to provide architecture services represented by three tiers of abstraction. These three tiers of architecture are required to transition from a strategic plan to a tactical proposal to an operation deployment in a logical and coherent manner. Architecture is rather simple when you have AaaS to do it right!
IT Architects provides an extensive list of Architecture services that lead an organization to a business outcome through IT architecture services. Rather than list them all in this article, you can find ITA’s Architecture-as-a-Service (AaaS) at: http://itarchitects.ca/architecture-as-a-service-aaas/. What makes this list real is that we can demonstrate how AaaS has enabled other organizations to develop their target architecture landscapes, and how AaaS provisions architecture services in order to realize value-add business outcomes. As a consulting firm specializing in Architecture-as-a-Service (AaaS), we can sit down with your management to understand your architecture requirements, identify required business outcomes, present the architecture AaaS deliverables to achieve them, define the scope of the initiatives, and provide resource and cost estimates to deliver your future-state architecture landscape.
Mr. Bob Ivkovic is a Principal with IT Architects in Calgary, Alberta. IT Architects (www.itarchitects.ca) is an information consulting firm specializing in business process optimization, system evolution planning, deployment of leading-edge technologies, and now Architecture-as-a-Service (AaaS). If you require further information, Bob can be reached at [email protected] or 403-630-1126.
