Comprehensive software reviews to make better IT decisions

Agile EA Operating Model

The relationship between Agility and enterprise architecture (EA) hasn’t always been a positive one in many organizations. The inability of EA processes to adapt to rapid incremental delivery approaches raises questions about the relevance of the EA practice. The framework presented below provides a structured approach to right-sizing EA to an organization’s context.

Situation

Today’s organizations are increasingly partnering with various external players in the business ecosystem to create unique value propositions. Digital technologies have played a critical role in helping to unlock business value that was not reachable before. The scope of the system is no longer limited to or contained within the organization but is rather integrated with partners/suppliers and various other players in the business ecosystem. As organizations get into a hyperdrive to be the first movers, the supporting EA processes also have to be adapted to the changing needs. To support the shift, traditional sequential software delivery approaches are being abandoned and more agile methodologies are being adopted.

Complication

It has become challenging to take a strategic approach while keeping up with the pace of change. As a result, EA has fallen out of fashion. The concerning fact is that EA is being totally abandoned when it can be used to help organizations handle uncertainty effectively. One of the root causes is the lack of understanding of EA and unwillingness to adapt EA processes to changing times.

Resolution

One must rewire the EA operating model by right-sizing it to evolving business needs and taking a deeper look into its fundamental components: Organization Structure, Engagement Process Model, and Architectural Governance. All three components of the EA operating model have to be adapted to an Agile environment to address the challenges facing EA practices.

At a very high level, we can categorize the work performed by an EA team into three work streams:

• Project support: Involves technical architects designing solutions that meet the business requirements while considering the business process, information, application, infrastructure, and security impacts.
• Standard setting: The primary objective of standard setting is to promote re-use and drive for economies of scale and scope.
• Architectural roadmaps: Looks at a broader organizational context to conduct architectural assessments to help identify areas for improvement to enable the organization to achieve its goals and objectives. Architectural roadmaps identify and prioritize initiatives that help the organization achieve its strategic goals.

Info-Tech’s framework to adapt EA to an Agile operating context can be represented as a 3X3 matrix to identify the implications.

Engagement Model Implications

Enterprise architecture is a strategic business technology function and hence interacts with several management practices within the organization. It is important to redesign the interaction points of EA within the organization as the management processes themselves are being optimized for agility.

• Project Support: Today organizations are moving away from one-directional flow of projects where business cases flow from the top down with benefits being consistently overinflated and costs deflated. In an Agile environment, emphasis is being put on clearly defining a minimum-viable product, prototyping the change, and scaling it when the benefits are observed in a control/ test group setting. The traditional business cases are being used to scale ideas/improvements rather than start them.

The implications of such a change is that the number of changes/feature sets being rolled out is increasing exponentially with iterative incremental releases. In a rapid, iterative delivery model, the volume and intensity of projects assigned to architects will inevitably increase. Thus, organizations that try to force fit the traditional resourcing model by assigning technology architects to projects run the risk of overstretching their teams. A different approach to resourcing will be needed in order to ensure that the project load is evenly distributed and manageable for the architecture practice.

The more practical approach to support such an environment will be to coach delivery teams to think like an architect rather than doing it for them. This would be more like a clock builder approach to architecture design rather than a time teller approach. In the proposed Agile engagement model, an organization should be able to make do with a few Enterprise Architects whose primary objective is to coach teams on creating/leveraging reusable components and applying tactics to reduce the total cost of ownership of technology. The coaching aspect can be more formalized through a center of excellence model.

• Standard Setting: In an Agile environment we need to take a radically different approach to setting standards. The conventional top-down approach of setting standards has led us down a path where the EA team is perceived as a bureaucratic function working from an ivory tower and standards being perceived as taxes on a project.
  In an Agile EA model, standards have to bubble up from the bottom with EA teams actively looking to identify patterns that are working for delivery teams. With the pace of technology change we are witnessing today it is virtually impossible to create standards in all areas. The team should be comfortable with the idea of not having standards and focus on optimization before standardization. The standard setting discussions should be facilitated in an architectural learning center (center of excellence) and voted on through a democratic process.
• Architectural Roadmaps: Enterprise Architects have always aspired to be business and technology strategic advisors, but the uncomfortable fact is that enterprise architecture means technology architecture with an enterprise scope for many organizations rather than EA with a business scope. A strategic disconnect with the business is one of the key challenges of an EA practice. As a result, the architectural roadmaps that recommend projects/initiatives are often ignored.
  Strategic planning should start with engaging business stakeholders to understand business goals and priorities. Architectural roadmaps across the business, information, application, infrastructure, and security domains should be unified in helping to achieve the same set of goals and objectives. Architectural roadmaps should take a minimum-viable approach and identify initial value points and show a path to scale value across the organization.

In one case, a large financial institution established an architecture learning center, which was facilitated by architecture team to train software developers and technical analysts on architecture skills. The learning center provided a platform to discuss technology trends and potential opportunities to standardize. The massification of architectural skills not only increased the employee engagement levels but also increased the number of reusable components being developed. The architectural learning center is an open-for-all platform that provides an opportunity for IT employees to expand their skillsets.

Governance Implications

The primary objective of architecture governance is to ensure that initiatives are aligned to strategic priorities and the solutions being designed are compliant with standards, thereby reducing the total cost of ownership of technology. Governance is all about decision making and a governance framework revolves around three fundamental questions:

• What decisions?
• Who makes those decisions?
• How do they make decisions?

The governance approach around the three streams of architectural work – project support, standard setting and strategic planning – needs to be adapted to an Agile environment.

• Project Support: In an Agile iterative delivery model, architectural reviews should be done by exception rather than as a norm. From a process perspective, architectural self-assessment templates should be developed and be part of the project management methodology. Furthermore, EA teams should play a proactive role in training practitioners on architectural models and promote reusable components through architectural learning centers.
  Architectural decisions at a project level should be primarily made by teams with a good understanding of the functional and quality expectations of the system. In situations when architectural self-assessments flag exceptions, Enterprise Architects should help the team address the concerns. In this model projects don’t flow through an architecture review board, rather the architecture reviews are done on an exception basis.
• Standard Setting: Establishing architectural standards has always been an opaque process and a heavy top-down approach. The adoption of those standards hasn’t always been a smooth process and it is a common occurrence that architecture exceptions closely proximate the number of architecture reviews. Invariably architecture exceptions lead to a higher amount of technology debt that the organization is accumulating.
  As the conventional top-down approach of standard setting is clearly not working, organizations need to democratize standards through an open voting process that involves practitioners. This approach will actively engage practitioners in the standard setting process and thereby increase compliance rates.
• Architectural Roadmaps: The primary decision-making body for approving architectural roadmaps should be the senior IT and business leadership. Enterprise Architects should take a business-first approach and leverage business architectural models to connect the informational, application, infrastructure, and security improvements. Enterprise Architects should seek seed funding to launch the minimum-viable product/solution and the approval of an architectural roadmap should be contingent on the success of the initial use case.

In one instance, a North American insurance provider disbanded its Architecture Review Board (ARB) and established an architecture center of excellence, whose mandate was to promote architectural discussions within the organization. Furthermore, the organization fine-tuned the architecture review process by publishing architecture self-assessment checklists and best practices. Initially the number of architecture exceptions quadrupled, but rather than addressing the deficiencies through a closed-door ARB review, the architecture team addressed the issues through evangelizing mitigating tactics through the center of excellence. As a direct benefit of such an approach, the number of architecture exceptions has gone down by more than 50% over a three-year horizon.

Practice Structure Implications

Enterprise Architects are senior business and technology strategists who have a strong understanding of business priorities and can identify business process, information, application, infrastructure, and security improvements. Rather than hiring or moving these senior professionals into one reporting relationship, organizations should explore a practice approach. In a practice approach we can make do with a few Enterprise Architects while tapping into the different teams across the organization for expertise. The practice approach provides more degrees of freedom to involve people from multiple teams (reporting units) into one common practice with shared goals and objectives.

In one instance, a Canadian bank reconfigured the EA team with Business Architects reporting to the COO organization and the IT Architecture reporting to the CIO organization. Bringing together both business and technology groups into one EA practice with shared goals and objectives encouraged collaboration between business and technology. As a result, architectural discussions were more focused on business-value delivery rather than technology excellence.

Recommendations

• Establish architectural learning centers to promote architectural discussions and increase the technical skills sets across the organization.
• Resource architectural team members from different teams within an organization into one EA practice with shared goals and objectives.
• Manage architecture reviews by exception rather than norm.
• Democratize standard setting through a transparent voting process that involves all impacted stakeholders.

Bottom Line

Adapt the enterprise architecture operating model to changing business conditions or run the risk of being irrelevant.

---

Want to Know More?

Review our Define an EA Operating Model publication for practical/tactical guidance.