The EA group has to create a governance framework that would be employed in the consistent design of EA artefacts, solution architectures and EA decision making process.
All stakeholders have to conform with the EA governance. For instance, stakeholders should check the EA before any investment in their field to determine the components affected, the platforms recommended and similar technologies already available so that the investment attains is objectives without creating duplication or overlay in the process.
Because architectural debt is created if "projects make decisions in isolation.
The governance should act through established and widely approved principles, control checkpoints in processes and project phases, roadmaps, strategies and decision making policies that establish who makes what decisions on which parts... The governance should be agreed beforehand rather than being elaborated on the run, as it happens today. One has to make sure though that the governance has input and meets the approval of all concerned parts. Governance should be approved by a more encompassing and different body from EA so that project architects and many other stakeholders may have a say.
Then, projects and activities should all submit to the governing rules and body, which body may not necessarily be the EA group but may have participation from. The Governance should be constantly reviewed and updated.
Governance reduces chaos. Governance avoids friction. Governance enforces integration, consistency and predictable results.
How do you design the target architecture if you do not discover and document first the architecture of what is out there? How could you expand a building without taking into account its current structure? You may end up transforming a barn in a concert hall.
In the absence of the current architecture, the enterprise may end up being re-designed from scratch at each cycle.
How could you plan a proper enterprise transformation if you do not know the current organisation and processes, the current systems and technologies, the as-is capabilities to act on their strengths and weaknesses?
How could you perform the gap analysis and establish the roadmap to the end state?
What would happen with the current platforms, skills and investments if you replace them when you ignore them starting from scratch?
How would the enterprise continue to deliver its products and pay your salary during such a transformation that may end up making you redundant?
The EA blueprint is about the current enterprise state. It enables the understanding, maintenance, fixing, improvement and transformation of the enterprise.
The enterprise evolves incrementally employing the existing processes and platforms rather than in revolutionary cycles. Even revolutions re-use existing structures.
Besides, a target enterprise that fails to consider the current operation and technologies would make your management cringe, to put it nicely. The transformation cost and risks would be insurmountable. Abandoning assets half way through their life cycle, unamortised yet, would waste investments. What would the shareholders and the investors say?
Too often though strategic transformations start, unfortunately without the architecture of the current enterprise. Too often the current EA is just embedded in people's minds. That increase the risks and costs of any transformation because nobody has the entire picture to make sure the transformation streams work towards that single goal. The current EA would make the transformation faster, cheaper, more effective, predictable and less riskier. The current enterprise architecture is a reference for the enterprise transformation because we refer to and transform what we have rather than building the enterprise from scratch.
So, where is the "story" idea coming from? To me the question is, are we turning our backs to "A picture says a thousand words"?
After all, EA is an architecture and the blueprint of the enterprise. At least, the words in the naming lead us to the logical conclusion that EA is a picture. And a building architecture is expressed in blueprints rather than stories, as we all know.
The story approach looks like springing from the popular tradition of employing plastic imagery, metaphors and comparisons to explain things in simple terms to people who have little patience, time and knowledge of the domain. And, at times, we may be all appreciating a well told simple story rather than the technical explanations.
It is also true that in recent times, even the professional literature is full of stories written in a colourful language rather than worded in the precise language of the profession.
A story may help stakeholders visualise how the enterprise will work after development. A story may come as a presentation to gain approval from the relevant stakeholders. The story is not used though to develop EA but to narrate the "change" for people to understand and subsequently approve it.
Anyway, it is not the EA architect that dictates the future state of the enterprise but the management, its vision and business strategy. Is it likely then that the strategy team puts together the story anyway.
What an EA architect has to accomplish then is to translate the story into use cases and target EA the that illustrate the impacts on processes, organisation, components and technologies of the enterprise.
The EA architect should devise the architecture that illustrates "how the new world would work" and the roadmap to show "what change would happen".
Nevertheless, should such a story be necessary, the teller function should be perhaps played by strategy and marketing teams. It is the marketing that usually illustrates how the "customer is made happy" for example.
Are we, the EA architects, in a position of command to tell stories and have the people listen? I doubt it. Would the management even expect the EA architect come with tales instead of pictures and roadmaps?
Ultimately, it is true that we have to "sell" the EA results as best as we can, by telling stories, if necessary. But that's not part of the EA development or utilisation process. Anyway, the architects have to be fluent in explaining the impacts of EA, stories or not. They should be indeed good communicators.
To conclude, stories may help certain audiences understand change by employing common language and light narrative. But stories are not how EA is done or represented though.
Source: it toolbox
Author: Adrian Grigoriu