By Iver Band, EA Principals Senior Instructor and ArchiMate Expert
Background
Several EA Principals clients have expressed a strong interest in operationalizing their enterprise architecture practice. What do they mean? Why is this important to them? And what can Enterprise Architects do to operationalize EA?
Merriam-Webster defines operational as “…b. ready for or in condition to undertake a destined function”. According to the TOGAF 9.2 standard, the destined function or purpose of EA is
…to optimize across the enterprise the often-fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.
The TOGAF Architecture Development Method (ADM) specifies an iterative method for developing enterprise architectures, overseeing their implementation, and maintaining their effectiveness in the face of internal and external change. The TOGAF Architecture Content Framework (ACF) provides a Content Metamodel with core concepts for architectural modeling along with a broad foundation for the architectural artifacts, deliverables, and reusable building blocks that Enterprise Architects can use to capture the status quo and collaboratively design a sequence of future states. The ADM and ACF, like all parts of TOGAF, can be customized to the needs of each organization and architectural initiative.
TOGAF provides ample guidance for producing EA deliverables that are accurate, relevant to the initiatives they support, reflect and address the concerns of key initiative stakeholders, and are accessible to their target audiences. However, architecture deliverables that do not guide actual implementations have no value. Therefore, the ADM Phase G: Implementation Governance specifies six steps for governing architecture implementation:
- Confirm Scope and Priorities for Deployment with Development Management
- Identify Deployment Resources and Skills
- Guide Development of Solutions Deployment
- Perform Enterprise Architecture Compliance Reviews
- Implement Business and IT Operations
- Perform Post-Implementation Review and Close the Implementation
This article does not substitute for the guidance in the TOGAF specification, which is well worth understanding and applying, but adds some Practical Principles that reduce the likelihood of EA waste, i.e., EA work products that are not used to develop, clarify, or implement business or technology strategy. The next section of this article sets forth these principles in the format recommended by Chapter 20: Architecture Principles of TOGAF Part III – ADM Guidelines and Techniques. Therefore, each of the principles there consists of a Name, a Statement, a Rationale and a set of Implications.
Practical Principles
Hear Stakeholder Concerns
Enterprise Architects build relationships in which stakeholders candidly express their desires and concerns regarding EA in general as well as specific EA initiatives.
Rationale
Unexpressed or unaddressed stakeholder desires and concerns can lead to incomplete or incorrect architecture requirements, deliverable reviews, or implementations. They can even lead to sabotage of EA activities.
Implications
Enterprise Architects develop relationships of mutual trust with architecture stakeholders at all organizational levels and maintain them through regular communication and fulfilled commitments. Enterprise Architects also get back-channel feedback about their stakeholder relationships. For example, they ask their manager or a mutually trusted colleague to ask a stakeholder how their joint work is progressing.
Effective Sponsorship
Enterprise Architects identify and cultivate the organizational leaders best suited to champion the development of the EA capability and the progress of EA initiatives.
Rationale
Even the best-justified and best-planned EA initiatives are unlikely to succeed if the people with the greatest influence on organizational culture and priorities do not communicate their value and priority.
Implications
Enterprise Architects identify the individuals and organizations on which EA effectiveness depends and consider who influences their culture and business priorities. They educate these influencers on the value and priority of each relevant EA capability and initiative and ask for their active support.
Required Deliverables
Standardized architectural deliverables are required for solution planning and delivery.
Rationale
If some solutions initiatives are allowed to proceed without EA involvement, then both the likelihood of their success and the organization’s ability to respond to change are reduced. Without systematic architectural work, the full impacts of planned solutions cannot be known, and subsequent solutions planning activities are more difficult and riskier due to a lack of accurate and current architectural models.
Implications
Enterprise Architects incorporate mandatory and standardized architecture deliverables into checkpoints in the systems planning and development lifecycle. They ensure that architecture work is an essential part of business case development as well as software development and acquisition processes.
Keep Pace
Enterprise Architecture work keeps pace with solutions initiatives within the scope of the EA practice.
Rationale
If Enterprise Architects slow down solution initiatives, the enterprise suffers from delivery delays and stakeholders often find ways to circumvent or ignore EA.
Implications
Enterprise Architects negotiate with stakeholders to define the scope of their practice based on business priorities as well as available resources and expertise. Within that scope, they limit their efforts to pragmatic guardrails that keep solutions initiatives aligned with business and technology strategy.
Enterprise Architecture, Solution Architecture, and Solution Development are complementary disciplines with clear boundaries. A community of Solution Architects produces standardized artifacts that Enterprise Architects review and Solution Developers implement. EA and Enterprise Agile frameworks are integrated so that EA deliverables remain relevant as new requirements emerge, and development teams gain experience with new technologies.
Integrate EA
EA is integrated with other business-critical management frameworks.
Rationale
EA overlaps other framework-based enterprise disciplines such as agile software development, project management, cybersecurity, service management and quality assurance. If the areas of overlap are not fully explored and resolved, the resulting confusion reduces the effectiveness of all disciplines. On the other hand, properly integrated disciplines foster mutually supportive efficiencies. For example, the EA templates for solution architecture review deliverables can be adapted to also meet the needs of cybersecurity, service management, and quality assurance reviews, which can occur simultaneously or in concert with EA reviews.
Implications
Enterprise Architects collaborate with experts and leaders in other disciplines to explicitly integrate frameworks. Integration points between frameworks are documented, communicated and reviewed regularly. Enterprise Architects work across disciplines to streamline governance processes with multifaceted guidance and review processes.
Continuously Improve
Enterprise Architects continuously improve EA repository content, standards and processes.
Rationale
Organizations, business conditions and technologies change constantly. Without continuous improvement, the EA capability loses effectiveness and relevance.
Implications
Enterprise Architects conduct regular review cycles for critical enterprise views, such as application and infrastructure portfolios and landscapes. They regularly solicit feedback from key EA stakeholders and apply it to improve their practice. Enterprise Architects measure the effectiveness of their practice using stakeholder surveys and interviews as well as objective measures such as the compliance of key domains with enterprise standards.
Spread Success
Enterprise Architects contribute to the success of people, projects and organizations through proactive collaboration.
Rationale
An EA practice that visibly contributes to the success of others is bound to get more support than one that obstructs and denies, regardless of the reasons given.
Implications
Enterprise Architects are generous with their time, expertise and empathy to advance the success of every individual, team and initiative with which they interact. They guide solutions architects, project managers, and business analysts. They collaborate to resolve issues before formal reviews so that those meetings run like pre-flight checks: critical yet nearly always routine due to careful preparation.
Capture and Communicate Value
Enterprise Architects capture and communicate the value they create.
Rationale
The practice of EA is often inconspicuous when new solutions or major upgrades go live. Kudos often go primarily to the development teams and the people and initiative managers that lead them. This exposes the EA practice to underfunding or circumvention, especially during episodes of organizational stress. Therefore, it is in the best interest of EA practices and the organizations they serve to systematically capture and communicate EA value.
Implications
Enterprise Architects collect both statistics and anecdotes that express the volume, quality, and impact of the work they do. They create compelling content that informs stakeholders about business and technology changes. Enterprise Architects communicate about EA value with stakeholders regularly through newsletters, presentations, websites and personal interactions.
Conclusion
These Practical Principles support the essence of successful and stable operationalization, which requires both the perception and reality that the practice of EA makes a critical difference in strategy implementation and responsiveness to disruptive change. Without operationalization, EA practices are, to the detriment of their enterprises, both ineffective and vulnerable. Enterprise Architects can strengthen their practices by adopting Practical Principles like these.
