We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

Is Enterprise Architecture a story?

Vote 0 Votes
Is EA a story? Nick Malik's post Enterprise Architecture as Story needs commenting upon.
To me the question is, are we going back on "A picture says a thousand words"?

After all, EA is an architecture or, if you like, the blueprint of the enterprise. At least, the words in the naming lead us to this logical conclusion. And any architecture is expressed in pictures rather than stories, as we all know.  

So, where is the "story" idea coming from?  

The story approach looks like springing from the popular tradition of employing plastic imagery, metaphors and comparisons to explain things in simple terms to simple people who have little patience, time and knowledge of the domain. And at times, we may be all appreciating a 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. 

Nick says "One of the most compelling things that an EA can do is frame the vision of a better future as a story... In my experience, every time an organization changed, there was a story at the heart of the change... that helped people to see how the change would happen, or helped to see how the customer would be happier, or helped to illustrate how the new world would work". 

From this statement one may conclude that the story is not used to do EA but to narrate the "change" for people to understand and subsequently approve it. But since change often comes independently of EA, the story approach may indeed apply to Change in general, rather than to EA alone. Moreover, the discovery and documentation of the current EA requires no change at all. 

And, in the case of the target EA, it is not the EA architect that dictates the future state of the enterprise, that requires the change, but the management, its vision and business strategy. Is it likely then that the management asks an EA architect, that routinely works in IT, to "frame" the story of the change that the business envisages? 

What the EA architect has to accomplish is to translate the change in the terms of the trade, that is, diagrams, roadmaps and principles to guide the transformation. The EA architect should devise the vision architecture to illustrate "how the new world would work" and the roadmap to show "how the change would happen". The architect should illustrate this vision state using use case scenarios rather than stories, in my view.

Nevertheless, if such such a story teller function is necessary, it should be perhaps played by the strategy, marketing teams or change teams. It is the marketing that usually illustrates how the "customer is made happy" for example.

Nick refers to Bill G., Steve J. and Nelson Mandela as story tellers. The comparison is flattering but are we, the EA architects, in a similar position of command to tell stories and have the people listen? I doubt it. Would the management even expect the EA architect to 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.

But for your part, do you think the EA architects should be story tellers and acquire narration skills? 

Enhanced by Zemanta


| Leave a comment

You ask whether EA architects should be story tellers. I believe there is no definitive answer, but the fuzzy answer is more "yes" than "no."
I work in the US Air Force, so we use the DoD Architecture Framework (DoDAF). DoDAF v2 encourages "fit for purpose" views that display data in a manner that should be driven by a stakeholder's interpretive needs to convert that data into information. Yes, Use Cases are huge in that process, but so is the need to actually talk with AND UNDERSTAND the stakeholders and how they assimilate data to make decisions.
I agree with Nick Malik that change drives the need for EA. The heart of EA is documenting "as is" enough to form a basis for a reasonable "to be" and then devise a transition plan (particularly a capital investment plan, whether talking physical or human capital) to get from one to the other. Change is endemic in that situation.
In a perfect world, the leaders/stakeholders can create AND ARTICULATE "the story" to motivate change, but in the real world I've found that task often falls to others, or the intitative fails completely. SHOULD the EA architects have to do that; no. But is it reasonable to expect that people who are in the business of designing decision support systems could help the stakeholders; I'll say yes. EA is all about communication. Often the architect is on the front line of getting a message from one level of responsibility (viewpoint) to another. The EA can mechanically say "not my job" or can be part of the solution. I want to work with the EA architects who envision themselves as the latter, not the former.

Steve, true, nothing is quite black and white, that is everything is fuzzy to a degree.

But fuzziness is more in our minds because we establish where the black ends and the white begins.
We deal with fuzziness every day but our decisions must be black or white. Otherwise we cannot ever make a decision.

Given the current definitions, architecture is still about pictures, it has always been, while stories describe (architecture related) experiences or rather eventual outcomes in our case.

Hence, you do architecture in pictures but you may talk about it in stories if you do not believe that a picture is worth a thousand words.

Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives