5 steps to minimum viable enterprise architecture

At Vault Health, CTO Steve Shi begins enterprise architecture (EA) work with a site survey of the entire IT, application, system, and data infrastructure but restricts it to two weeks with one-hour interviews about each function.

Customers, whether employees or those paying for a product or service must “love” the result of this minimum viable approach to EA, says Shi. “If you don’t get customer buy-in, you will lose momentum, and if you lose momentum, it’s harder to continue to iterate after the minimum viable launch,” he says.

Like many IT leaders, Shi is trying to strike a balance between complex architectural studies that sit unused and bare-bones EA reports that lack enough scope and depth to provide lasting value. Finding that balance requires staying close to business needs, slashing busywork, scoping the project properly, and setting and enforcing the right architectural standards and principles. Here are five steps CIOs who are veterans of the process recommend.

Stay close to the business

Maintaining close communication with business stakeholders is the only way to know where a minimum viable enterprise architecture can best help the business and drive funding for continuing EA assessments as business needs change.

At Carrier Global Corp., CIO Joe Schulz measures EA success by business metrics such as how employee productivity is affected by application quality or service outages.

“We don’t look at enterprise architecture as a single group of people who are the gatekeepers, who are more theoretical in nature about how something should work,” says Schulz. He uses reports and insights generated by EA tool Lean IX to describe the interconnectivity of the ecosystem as well the systems capabilities across the portfolio to identify redundancies or gaps.  This allows the global provider of intelligent building and cold chain solutions to “democratize a lot of the decision-making…(to) bring all the best thinking and investment capacity across our organization to bear.”

George Tsounis, chief technology officer at bankruptcy technology and services firm Stretto, recommends using EA to “establish trust and transparency” by informing business leaders about current IT spending and areas where platforms are not aligned to the business strategy.  That makes future EA-related conversations “much easier than if the enterprise architect is working in a silo and hasn’t got that relationship,” he says.

Trim the red tape

Lengthy questionnaires and template-driven interviews are a familiar, and often unwelcome, part of EA efforts. Minimum viable EA practitioners suggest eliminating any questions that don’t deliver essential information and allow for feedback from users.   

Gregor Hohpe, director of enterprise strategy, at cloud hyperscaler Amazon Web Services, recommends moving from “heavy-weight, largely one-way” EA processes to simpler, faster and iterative conversations with business users.

At financial services firm State Street, Global Chief Architect Aman Thind tries to streamline the EA process by asking only precise and relevant questions, rather than everything in an EA template. Focusing on the most essential questions can cut the time required for architecture review and submission by at least half and makes the process much more effective, he says. For example, the framework a SaaS application uses to deliver the user interface is less important than the identity and access management procedures that determine how users interact with it.

Along with using automated compliance checks and self-service platforms, Hohpe recommends eliminating “endless lists of standards that largely get ignored,” holding review meetings where all documents are reverse-engineered from the respective team’s preferred outcome, “alignment” meetings on non-value adding topics, and “generating giant tapestries from heavy-weight EA tools that are never used for decision-making.”

At Vault, a digital health care company, Shi finds application observability tool New Relic valuable in speeding EA work by providing instant visibility into the entire architecture.

 He also uses new terms and processes to avoid common slowdowns and create awareness of his novel approach. One example is a “site report” that asks users to envision the final EA product. This helps define critical requirements such as the number of transactions and types of processes an application must support, “coming from the customer side and working backwards.” Rather than using a “one and done” process of asking users to agree on a critical technology decision up front, Shi challenges them to confirm or revise “development hypotheses” such as the number of database calls a system must support each day. This approach speeds agreement on choices of components such as databases, he says.

During application rollout, Shi avoids a generic project plan in favor of what he calls “a specific macro sequencing plan” of steps built around milestones such as alpha and beta tests and their associated validation milestones. This defines, for each stage in the deployment, success in business terms such as revenue or user adoption rate and lessons learned from the support process that reduce ongoing support costs. It also reminds everyone, he says, that “the project does not end until we know the architecture has delivered measurable customer value.”

Scope it right

Take on too much in a minimum viable EA project and it will be outdated before it is done, delivering results too late to satisfy and receive future funding from business leaders. Narrow it too much and it won’t deliver the comprehensive view of technology and the business needed to make the most of IT investments. Reaching the proper balance often requires focusing on one application or pain point in the business or an area where requirements are changing rapidly due to new business or regulatory needs.  

Gartner Inc. Associate Principal Analyst Nolan Hart calls the proper EA scope “the least number of deliverables, such as viewpoints, reference models and design patterns, that help ensure timely, compliant delivery of products and solutions.” Rather than spending too much time understanding the current architecture, he recommends, “first understand your desired outcomes.” There is no value, he says, in getting “lost documenting your current dysfunctional architecture forever and ever and ever.”

Shi recommends a minimum viable EA consider “everything from the user interface to the APIs that link systems to the data architecture, rather than a single siloed component or service.” The proposed architecture must also be testable at production scale, he says, and handle the same peak requirements as the system it replaces.

Proper scope also applies to the EA organization. Rather than a dedicated EA group, Carrier created centers of excellence for key needs such as CRM, field service, ERP, analytics, and digital factory capabilities. These centers provide a simplified foundation of core components that allow it to quickly innovate without requiring an EA exercise to evaluate separate platforms for each business unit, says Schulz.

If one group within a business isn’t interested in a minimum viable EA project, “ there are plenty of other people who will take your time,” says Hart. Match that demand with the skills of an EA  group to determine “three to five types of services you can offer to deliver those business outcomes with a minimum viable approach.”

Set and enforce standards

Amazon Web Services

Enforcing design principles, along with a focus on business needs, can help shorten “religious arguments about which solution is best,” says Tsounis.  The principles he encourages include “always try to create the simplest possible solution, don’t overengineer, allow for maximum reuse across the organization, leverage established architectural design patterns as well as cloud-based services before building something new.”

Reference architectures and standards in areas such as cybersecurity, data governance, production management, and deployment best practices provides a “ready-made playbook” to efficiently build composable applications that are robust, compliant, and resilient by design, says Thind. Such architectures, built of microservices that are “very well-defined … in terms of their APIs, their scalability, and how they interoperate” allows a business to replace any microservice without affecting any others, thereby creating a future-proof design. 

Hohpe says some standards stifle innovation while other boost it. For example, uniform interfaces are essential to creating easy-to-adapt architectures. However, overly strict standards can lead to poor technology choices. He remembers one application team that chose XML as a component interface over faster communication protocols. When asked why, the team replied that the architecture team required it, apparently without considering the detrimental effect of XML parsing on application performance.

Start somewhere

If nothing else, says Thind, appoint a “…a chief architect, an executive assessing the overall standards, the overall governance, the overall platforms and the overall discipline of application design right from the top. Just having that position signals the importance of architecture to the entire firm and instills the right behaviors we need to create efficient and innovative IT organizations.”

Beginning a minimum viable enterprise architecture can begin by simply “taking stock,” says Thind, identifying overspending such as “why do we have six different applications for the same process, five different contracts (for) the same BI tool, multiple market data contracts with the same scope, 24×7 Hadoop clusters for monthly reporting, and so on.” But even such a minimum viable effort can pay big benefits. “Just ensuring the right tool is used for the right job and there is standardization and best practices around their usage can make a considerable impact to the bottom line and lead to less technical debt, reduced support requirements, and allow more rapid innovation,” he says.