By way of example, sometime ago I was requested to assist two large programs of work delivering distinctly separate line of business applications. Each program of work was a multi-year and multi-million committed by the enterprise. Whilst the business case and initial scope of work for each program had identified bi-directional systems integration as a significant enterprise benefit, a lack of strong stakeholder support resulted in each program of work de-scoping integration due to schedule and budgetary pressures.
With scope adjusted the architects for the solutions did not consider integration concerns within the architecture. In fact any consideration to integration was so minimal that in future it would eventually turn out that there were significant limitations in the level of integration that could be achieved in one of the platforms. Significant business benefits were at risk of not being realised.
This is just one example where program governance decisions made during program delivery have directly impacted the longer term enterprise architecture vision. Whilst I won’t go into detail of the activities required to take corrective action for the programs in my example, or the political turmoil that ensued, it brings to light shortfalls in the governance frameworks adopted in such organisations.
Whilst the difference between Architecture Governance and Program Governance in large programs of work is a topic for a separate discussion, for this post however I’m more interested in exploring what I believe individual practitioners can do to mitigate deficiencies in governance decision making.
As individual architecture practitioners, it is unrealistic to think we can always influence governance decision making to favour architectural outcomes. You win some, and you lose some, however we can consider some of the following practices as mechanisms to protect the architectural integrity in the interests of the enterprise vision;
“Bottom-up and Top-down” awareness
First learn the meaning of what you say, and then speak – Epictetus
Today more than ever, it is essential to remind ourselves that as Architecture practitioners we all play a part in delivering to an enterprise architecture, regardless of role and position description. Therefore practitioners need to be conversant and supportive of each architecture discipline and its purpose within an enterprise. This is necessary as markets become more dynamic and enterprises seek to become more responsive or ‘agile’.
Program Architects and Solution Architects need to be conversant in enterprise architecture parlance, the framework adopted within the enterprise and the published Enterprise Architecture artifacts such as road-maps, capability maps and motivation models etc. Armed with this knowledge, the Architect will be more prepared and capable of challenging potential Program/Project scope changes that could impact the integrity of the enterprise architecture itself.
On the flip side, Enterprise Architects should be well-informed of the business, technical and governance challenges that will exist in the delivery of solutions that have been scoped as part of the Enterprise Architecture planning process. Through the formulation of the roadmap and scoping of required program/s of work, the Enterprise Architect, or nominated Program Architect, must ensure that dependencies are identified and risks associated with delivery are acknowledged early. This not only provides a more considered foundation for a Solution Architect to begin with, but also ensures that downstream impacts of the program delivery structure have been considered. Deficiencies in the aforementioned knowledge domains and a lack of investment upfront in program of work planning, especially in the business and technical dimensions, will limit the Enterprise Architects ability to advise and support architecture practitioners when confronted with problematic governance decisions.
Architecture Scope IS NOT Program/Project Scope
Whether a practitioner is engaged as an Enterprise Architect, Program Architect, or Solution Architect, his/her initiative is typically bound within the scope of a particular planned initiative. However the initiative scope should not be the sole basis for the scope of architecture analysis. This assertion, I believe, applies to all architecture disciplines.
The program/project scope is, typically, defined along Schedule, Cost and Quality dimensions (I’ve simplified here in the interests of brevity). Each of these aspects of a program/project scope are important to manage the delivery of the end solution, however I’m yet to see any program/project management plan or statement of work that includes “realising enterprise architecture outcomes” as a project objective. This is why the Architecture practitioner is typically responsible for ensuring the ongoing alignment of the solution with the enterprise architecture.
Take the Enterprise Architect required to define a Segment Architecture for a new Service Management business unit (example figure below) which includes business services that are consumed by external stakeholder groups (customers) and interacts with a number of internal services to deliver said services.
The definition of said architecture would be undertaken within a defined engagement scope or conceivably encapsulated within a broader strategic initiative. However should the desired internal services be revised to a subset of those originally intended, the architecture should continue to consider the de-scoped services regardless. The extent to which the architecture analyses and defines these services may be constrained to Use Cases only, for example, depending on the level of risk it represents to realising the longer-term business outcomes. Without any type of analysis, the architecture defined could limit the enterprises ability to eventually address the previously de-scope internal services or, worse still, lead the enterprise into a whole new change program.
Similarly, a Solution Architect required to define an Architecture for a new line of business application would be engaged within the scope of an approved delivery project. In the event the project scope is revised to exclude important functions that have a broader strategic benefit, the Solution Architect should continue to include these functions within analysis and definition activities. Again, consideration of the functions may be at the Use Case level, or even System and Sub-system context. Either way a level of analysis that is commensurate to the strategic importance of the function should be undertaken.
Through accepting that an architecture should not be explicitly constrained by program/project scoping dimensions, practitioners can produce architectures of greater enterprise value and reduce potential for the re-occurrence of examples like the one I provided at the start of my post.
Understand the political landscape
Within any delivery program/project, the architecture practitioner is critical to successful delivery through the removal of uncertainty as it relates to Business, Information, Application and Technical dimensions. Understanding the political landscape inside and outside the program/project in which the practitioner is engaged is important to understanding how to influence governance decision-making.
Practitioners need to work as peers with Program/Project managers, regardless of the project or business hierarchy. An Architect needs to have the courage to challenge decisions that may impact the ability of the architecture to deliver to business outcomes. This will lead to a tension between the roles, however this should be viewed as natural given the distinctly different focuses of the disciplines. An architecture practitioner who understands such a working relationship is more empowered to challenge decisions through appropriate channels, not just operate as a subordinate to a Program/Project Manager.
Similarly, close relationships with business stakeholders will help influencing decision makers. This is not just IT stakeholders, but those who will be the consumers of the solution itself. In some instances access to stakeholders may be limited based on program/project structure, however you should take any opportunity you can to access said stakeholders and become known to them. Having close relationships with business stakeholders is critical to being able to influence governance decision-making.
Finally, with the aforementioned knowledge of enterprise architecture practice, start leveraging the Enterprise Architecture practice in the way it was intended. Establishing a close working relationship with the Enterprise Architect who is responsible for the domain in which you are working is the first step. Engage them directly, regularly and actively regarding architecture scope, risks and issues. An engaged Enterprise Architect can assist in opening doors to stakeholder groups and tackling governance decisions that may impact the enterprise architecture vision.
Architecture Practitioners of all levels and experience can support the delivery of successful business outcomes greater than the development of architecture deliverables constrained by the initiative scope. As practitioners we must do more to deliver an architecture that is aligned with an enterprise vision and should engage outside of a project construct to be adequately prepared to challenge decisions that may be an impediment to this objective.
