How to Define EA Projects
Enterprises cannot be put in dry-docks while their architecture is overhauled. As a corollary:
- Scope cannot be fully defined up-front, if only because the whole enterprise, including organization, could possibly be of concern.
- Fixed schedule is to be avoided, lest each and every unit, business or otherwise, would have to be shackled into a web of hopeless reciprocal commitments.
- Different stakeholders may come as interested parties, some more equal than others, but none with undisputed prerogatives.
So, instead of preformatted processes with explicit inception and completion, EA ventures should come as loose collections of business-driven and architecture-based projects managed through some kind of upgraded backlog.
The challenge is to align clear and present business objectives with long term architectural ones, and to set a convincing path to their achievement. Hence the need to circumscribe the perimeter of projects and to be specific about the engineering options.
Separate Processes from Structures
Architectures are made of shared assets and mechanisms whose life cycle is supposed to last well beyond current specific business processes. Hence the need to be explicit about what pertain to business opportunities on the one hand, the footprint of changes on organization and systems on the other hand.
Align Practices, Methods, and Tools
If EA is to become an intrinsic and perennial quality of an enterprise, it must be built on consensus. That can only be achieved through a smooth learning curve that weaves together practices, tools, and methods. To that effect new projects should contribute to the integration and improvement of existing modus operandi.
Plan for Iterations
At the end of the day success will be decided by the fruitful combination of enterprise assets (financial, technical, human) and business context and objectives. Defining their respective life cycles and planning the necessary changes could be seen as the primary responsibility of enterprise architects. But since that enterprises are to keep sailing, EA projects are by nature continuous and iterative.
How to Pitch the Pagoda Blueprint
Consultants can take advantage of three key arguments: neutrality, interoperability, learning curve.
Neutrality: Independent Consulting
EA choices bear upon a wide range of enterprise activities, organization and systems, inducing deep and long-term consequences. Enterprises relying on external consulting should therefore be assured of the neutrality and transparency of decision-making processes, and of a transfer of expertise. That can be difficult to achieve if EA undertakings are tied to big consulting firms with their own proprietary methods and tools.
On that account the Pagoda blueprint ensures open field and free hand to consultants, with no strings attached.
interoperability: Comprehensive & ecumenical framework
On the one hand EA should not be attached to any specific engineering platform, whatever its merits, on the other hand EA projects should be anchored to commonly accepted architectural concepts as to ensure their interoperability with leading engineering platforms.
On that account the Pagoda blueprint ensure interoperability through four well understood methodological bridges: Zachmann (for modeling), Agile and use cases (for business-oriented projects), and MBSE (for engineering processes).
learning curve: thorough documentation, on print and online
Enterprise architecture is a continuous endeavor that can only be built on internal consensus and carried out through collaboration and collective learning. That kind of learning must combine feedback from experience with extensive in-depth yet non-proprietary documentation freely available.
On that account the Pagoda blueprint comes with a book that uses knowledge managements and latest technologies to integrate business and systems perspectives, an extensive online documentation with thousand of monthly readers, and an open-sourced ontological kernel.
- The Book: EA Fundamentals
- EA: Work Units & Workflows
- Enterprise Architecture Booklet
- EA in bOwls
- Enterprise Architectures & Separation of Concerns
- Where to Begin with EA
- Frameworks: How to Avoid Quagmires
- Hit The Caminao Ground Running
- Models Transformation & Agile Development
- Agile Architectures: Versatility meets Plasticity
- Agile & Dynamic Programming.
- Abstractions & Emerging Architectures