Enterprise and solutions architecture (ESA) leaders typically strive to increase their practice’s contribution to their organization. The TOGAF® standard, which includes fundamental content and a variety of guides, offers myriad approaches. Methods and techniques abound for improving architecture practices and enhancing the value they deliver, but organizations vary tremendously in their size, complexity, immediate needs, and architecture maturity. The minimum viable product (MVP) approach that is widely embraced in digital product development today, however, applies to ESA. Selecting the next MVP to deliver, however, is highly situational, but there are some relevant general principles.
An MVP “is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.”[1] ESA leaders should introduce new methods, processes, artifacts, and tools with just enough substance to gauge their effectiveness. The MVP approach is widely accepted in product development today, but it is also important in ESA, since enterprise value manifests when architectures are implemented, not when they are developed. Therefore, all innovative approaches should be watched carefully to ensure that they are delivering enduring value. It is not sufficient to complete and promote a checklist of best practices. The value of ESA must be captured and compared with its costs, like every other investment in today’s competitive enterprises.
With the MVP approach as context, there are several more specific approaches to enhancing ESA value. Engage in continual conversations about expectations and value with key stakeholders, beginning with the leader to which the ESA leader reports. Often that more senior leader has specific ideas on ESA based on successes elsewhere and expects the ESA leader to recreate them. There is nothing wrong with trying approaches that have been successful elsewhere—consensus on these approaches is the basis of standards like TOGAF—but organizations are unique and dynamic, so frank dialogue about the readiness of the organization to change and reactions to innovative approaches is critical. After several cycles of stakeholder conversations, innovative approaches, and observations of their effects, the mission, vision, and value proposition of the ESA practice should be created or revisited and ratified with those key stakeholders.
Make ESA play a critical role in initiatives in which the enterprise cannot fail. For example, capturing the current state of the application portfolio and setting up clear accountability for each application may be critical to a compliance initiative.
Develop allies with whom the ESA leader can adapt and adopt proven methods and show their value. For example, it may not be possible to get top executives to mandate capability-based planning, and some of their direct reports may be skeptical. But capability-based planning may also resonate well with other leaders, who may provide an opportunity to pilot it in their organizations.
Consider enterprise and solutions architectures as peer disciplines that depend on each other, rather than considering enterprise architecture only as the governing discipline. In some organizations with minimal or missing architecture practices, applying sound approaches such as interdisciplinary and management architecture reviews to a single solution may win the support for the idea of consistency and alignment across all solutions. Solutions architecture can be practiced in an enterprise context, which may have to be defined in flight, but then can serve as the basis for enterprise architecture guidance.
Rarely does an ESA leader have all the solutions architects in an organization reporting to them. However, the ESA leader can create an architecture practice consisting of enterprise and solutions architects with a common language and way of working, so that architects with diverse technical and functional expertise can collaborate effectively.
The ESA must design and implement this common mindset and method by carefully choosing and teaching essential concepts and methods from multiple sources, asking architects to apply them, and asking for feedback. In this way, architects feel engaged in developing the ESA practice and are more likely to contribute to it in the future.
Finally, it is also important to select the simplest possible tools, and to make sure that all data, such as architectural models, kept in tools produces value that compensates for the effort of keeping that data correct. The implementation of tools that require unique skills and complex procedures can easily distract an ESA practice from its mission.
All these practices may not apply to organizations with very mature architecture practices, or to those with large and influential architecture teams. But for many ESA leaders who look to advance their practices, they are worth considering.
Authored by Iver Band, EA Principals Senior Instructor and ArchiMate Expert
[1] https://en.wikipedia.org/wiki/Minimum_viable_product retrieved 9/24/2023.