EA Maturity Today: Goals for Continuous Transformation
IT planning is no longer a linear “As-Is” to “To-Be” process. Rather, innovation at an enterprise-level means balancing a multitude of digital transformations at once — all of which are interconnected and have no clear end date.
A confluence of common IT change events — from cloud migrations to ERP roll-outs to M&As/carve-outs — is leading businesses to prioritize adaptable plans over conclusive implementations. In many cases, metrics like rate of change even define an architecture’s value and shape decision-making overall. The popularity of Gartner’s pace-layering strategy is evidence of this paradigm shift.
But these ideas didn’t emerge overnight. The past decade gave rise to the technology and disruptive business environments that make today’s continuous transformation a possibility and a necessity. What’s also occurred within businesses worldwide is a transition — either partially or wholly — to product-based IT delivery environments dedicated to improving resilience, reducing uncertainty, and testing hypotheses.
Put another way, the penchant for constant transformation native to Silicon Valley technology companies is now common throughout traditional industries.
Ridge Venture’s Yousuf Khan discussed on Unleash IT how companies use, build, and deploy more software than ever before to expand offerings — and, quite understandably, struggle to re-configure these interdependent systems in their transformation journeys.
“People are waking up to the fact that their enterprises are driven by software,” said Khan. “If you haven’t structured your data and your applications right, you’re going to be digging yourself into a big hole.”
That’s why companies are re-thinking enterprise architecture (EA) to prevent such transformation bottlenecks. Enabled by data-driven EA tools connected to ecosystems of best-in-class software, these groups place a high emphasis on unlocking tangible business value from architecture. Among others, key characteristics of modern EA programs include accessible data platforms and accelerating roll-outs and time-to-value.
According to Gregor Hohpe, author of The Software Elevator, architecting in today’s enterprise also involves the following:
- Knowing whether something is architecture in the first place
- Being able to sell options to the business
- Tackling complexity by thinking in systems
- Creating cultures of change
- Automating everything and making the rest self-service
- Thinking like software developers as everything becomes software-defined
- Building platforms and setting standards that don’t stifle creativity
- Navigating IT landscapes with undistorted world maps
But in what ways should EA programs grow their capabilities and succeed in the world of product-based IT delivery and continuous transformation?
Though there are many process- and framework-driven recommendations, there’s no uniform path to a multi-dimensional EA program. Some programs evolve without clear structures and architecture review boards; others adopt highly formal and restrictive parameters. In the end, EA programs mature in ways that reflect the uniqueness of their end customers’ journeys and organizational setups.
To increase the maturity of EA programs and support unique continuous transformation journeys, LeanIX recommends using five models that are based on realities seen in our customers:
1. Ad Hoc
Most EAs recognize the limits of using Excel sheets and Visio diagrams to manage IT landscapes. In addition to low-quality and manually-collected data, these methods make answering common EA Questions like “how many applications are in Country A” or “which systems are compliant with GDPR regulations” a challenge. This is especially true for EA teams with limited resources.
As IT and business teams converge during transformation projects, EAs are required to answer a high volume of ad hoc questions. They must also connect stakeholders from across business units to unearth more data and discuss findings. EA teams must be staffed with diverse personnel to simplify this outreach. As well, to give stakeholders an easier way review materials, knowledge-sharing and storage should occur via more data-driven and collaborative platforms.
- Create a single point of truth
- Staff EA team with the right resources (e.g., internal consultant, diverse representatives, etc.)
- Create a free space for scaling/maturing
Limited visibility into IT landscapes, incomplete business capability maps, unclear ownership of applications: EA programs can’t drive change if they can’t provide on-demand clarity on technology and business portfolios. This means seeing the business value of applications at a holistic level while also measuring their underlying functional and technical fit. It also means letting users set configurable overlays and self-generate reports — from business to technology architecture layers — for faster insights.
This clarity, however, has to be built atop sustainable EA practices which grow as companies scale. For example, the aforementioned pace-layering model from Gartner can be applied to business capabilities to help EAs identify the different ways innovation occurs in multi-tiered organizations. Segmenting capabilities by their pace of change helps to create more predictive environments, prioritize governance, and alter perceptions of technology’s static nature — thereby ensuring transformation activities occur on time and with appropriate levels of detail.
- Establish ownership and collaboration around EA assets
- Pace-layer business capabilities to drive business-IT alignment
- Drill-down where necessary
Today’s EA programs rely on automation to update and maintain IT repositories. To do so, company-wide systems are integrated to EA tools through APIs to coordinate regular information flows. This efficiency is what makes it possible to build systems of records in global enterprises on applications spanning the IT value stream.
When looking at the Open Group’s IT4IT value stack, an EA tool fits well with the Strategy to Portfolio space — especially when integrated with cloud, microservice, and SaaS discovery mechanisms. Nonetheless, automation processes still require human intervention, and in order to prevent issues like duplicated data, these information pathways must be designed properly.
- Eliminate double data entries through integration
- Establish EA tool as a system of record for applications
- Focus on accurate, higher-level information in EA tools; deep dive into systems of record
4. Business Outcomes
Beyond understanding their business’s strategic goals, EAs must rely on change roadmaps and success KPIs to anchor their activities to tangible, solution-oriented plans. Agendas should reflect long-term architecture outlooks and short-term business priorities, and progress must be tracked over time and readily communicated to decision-makers. KPIs depend largely on where a company is on their EA journey, but “quick-win” focal points are often cost-based and relate to improving data quality, decreasing complexity, and minimizing redundancy.
No matter the plan or KPI, actions will inevitably run up against the present realities of businesses and the political interests of stakeholders. Architectural changes can potentially impact all organizational levels, and to navigate conflicting interdepartmental visions, criteria-based decision-making (e.g., with Gartner’s TIME model) is essential.
- Offer clear and pragmatic solutions
- Translate and relate business KPIs with EA KPIs
- Make commitments and get a seat at the table
- Use transparent, criteria-based decision models
There is likely to be more transformational projects than resources in EA teams. As a result, EAs have to put practical options on the table for future IT states and set businesses on achievable paths to success (i.e., be realistic). Transformational EA programs do so by employing a combination of high-level and granular plans to review implementation scenarios from numerous angles. This includes generating reports on how capabilities might change as a result of a potential project and how to manage the technical dependencies involved.
Using SAP S/4HANA transformation as an example, greenfield versus. brownfield approaches are to be evaluated in advance, as are the potential bottlenecks in the process. Documenting and analyzing the impacts of a project — by transferring or creating relations, adding or removing custom tags, and setting technical and functional fit ratings plus business criticality scores — before changes occur can greatly assist EAs when doing so.
- Offer options for the future state of the business and IT
- Develop IT-led initiatives to transform the business
To conclude, EA maturity in the world of continuous transformation is synonymous with flexibility and multi-dimensional views.
Foundational activities within today’s mature EA programs include establishing single sources of truth to offer shared understandings of IT and business landscapes for cross-departmental EA stakeholders. Once this is in place, automation and integration are required to keep information up to date and to increase overall acceptance in transformations.
EA-specific KPIs related to transformation initiatives (e.g., application rationalization, cost reduction, data quality improvement) act as internal guides for this process which also help external parties better understand architectural missions. Automation and integration are required to keep this information up to date and increase overall acceptance in transformations.
It’s important to note, however, that a truly mature EA program means being an on-the-ground partner in innovation and change initiatives — not just a tool-based governance and support function.