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.\n\nCustomers, whether employees or those paying for a product or service must \u201clove\u201d the result of this minimum viable approach to EA, says Shi. \u201cIf you don\u2019t get customer buy-in, you will lose momentum, and if you lose momentum, it\u2019s harder to continue to iterate after the minimum viable launch,\u201d he says.\n\nLike 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.\n\nStay close to the business\n\nMaintaining 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.\n\nAt 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.\n\n\u201cWe don\u2019t 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,\u201d says Schulz. He uses reports\u00a0and insights\u00a0generated by EA tool LeanIX\u00a0to describe the interconnectivity of the ecosystem as well the systems capabilities across the portfolio to identify redundancies or gaps.\u00a0 This allows the global provider of intelligent building and cold chain solutions to \u201cdemocratize a lot of the decision-making\u2026(to) bring all the best thinking\u00a0and investment capacity\u00a0across our organization to bear.\u201d\n\nGeorge Tsounis, chief technology officer at bankruptcy technology and services firm Stretto, recommends using EA to \u201cestablish trust and transparency\u201d 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 \u201cmuch easier than if the enterprise architect is working in a silo and hasn\u2019t got that relationship,\u201d he says.\n\nTrim the red tape\n\nLengthy 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\u2019t deliver essential information and allow for feedback from users. \n\nGregor Hohpe, director of enterprise strategy, at cloud hyperscaler Amazon Web Services, recommends moving from \u201cheavy-weight, largely one-way\u201d EA processes to simpler, faster and iterative conversations with business users.\n\nAt 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.\n\nAlong with using automated compliance checks and self-service platforms, Hohpe recommends eliminating \u201cendless lists of standards that largely get ignored,\u201d holding review meetings where all documents are reverse-engineered from the respective team\u2019s preferred outcome, \u201calignment\u201d meetings on non-value adding topics, and \u201cgenerating giant tapestries from heavy-weight EA tools that are never used for decision-making.\u201d\n\nAt 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.\n\n He also uses new terms and processes to avoid common slowdowns and create awareness of his novel approach. One example is a \u201csite report\u201d 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, \u201ccoming from the customer side and working backwards.\u201d Rather than using a \u201cone and done\u201d process of asking users to agree on a critical technology decision up front, Shi challenges them to confirm or revise \u201cdevelopment hypotheses\u201d 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.\n\nDuring application rollout, Shi avoids a generic project plan in favor of what he calls \u201ca specific macro sequencing plan\u201d 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 \u201cthe project does not end until we know the architecture has delivered measurable customer value.\u201d\n\nScope it right\n\nTake 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\u2019t 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. \n\nGartner Inc. Associate Principal Analyst Nolan Hart calls the proper EA scope \u201cthe least number of deliverables, such as viewpoints, reference models and design patterns, that help ensure timely, compliant delivery of products and solutions.\u201d Rather than spending too much time understanding the current architecture, he recommends, \u201cfirst understand your desired outcomes.\u201d There is no value, he says, in getting \u201clost documenting your current dysfunctional architecture forever and ever and ever.\u201d\n\nShi recommends a minimum viable EA consider \u201ceverything from the user interface to the APIs that link systems to the data architecture, rather than a single siloed component or service.\u201d The proposed architecture must also be testable at production scale, he says, and handle the same peak requirements as the system it replaces.\n\nProper 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.\n\nIf one group within a business isn\u2019t interested in a minimum viable EA project, \u201c there are plenty of other people who will take your time,\u201d says Hart. Match that demand with the skills of an EA group to determine \u201cthree to five types of services you can offer to deliver those business outcomes with a minimum viable approach.\u201d\n\nSet and enforce standards\n\nEnforcing design principles, along with a focus on business needs, can help shorten \u201cphilosophical arguments about which solution is best,\u201d says Tsounis. The principles he encourages include \u201calways try to create the simplest possible solution, don\u2019t overengineer, allow for maximum reuse across the organization, leverage established architectural design patterns as well as cloud-based services before building something new.\u201d\n\nReference architectures and standards in areas such as cybersecurity, data governance, production management, and deployment best practices provides a \u201cready-made playbook\u201d to efficiently build composable applications that are robust, compliant, and resilient by design, says Thind. Such architectures, built of microservices that are \u201cvery well-defined \u2026 in terms of their APIs, their scalability, and how they interoperate\u201d allows a business to replace any microservice without affecting any others, thereby creating a future-proof design. \n\nHohpe 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.\n\nStart somewhere\n\nIf nothing else, says Thind, appoint a \u201c\u2026a 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.\u201d\n\nBeginning a minimum viable enterprise architecture can begin by simply \u201ctaking stock,\u201d says Thind, identifying overspending such as \u201cwhy 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, 24x7 Hadoop clusters for monthly reporting, and so on.\u201d But even such a minimum viable effort can pay big benefits. \u201cJust 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,\u201d he says.