Enterprise Architecture and stakeholders' plans

EA was compared to city planning. One needs to plan infrastructure like roads, water and gas pipes tracts, electricity and telephone cables then shopping malls, official buildings, entertainment venues etc. There are blueprints for electricity wires, sewage pipes, road maps and tourist maps... They all together form the city map.
At the same time towns are the result of an organic evolution over centuries of spontaneous building in various fashionable architectural styles. US cities are planned to a degree few other cities are because the rectangular grid was planned early in the city lifecycle. But most cities build around old cities. Few are constructed from scratch. As such architecture is about managing the change from one state to another, in small increments of time and realizations.

What is EA about though? In an Enterprise, we have all these plans for the CRM, datawarehouse, portal, printing and floor maps, networks, manufacturing band, building, locations... Every stakeholder with his own plan. But they are designed taking into account different components, different diagramming techniques, symbols, tools... Each and every map is useful to a small community.

EA relates all these architectures in a whole where one can navigate from one item to another in a logical manner. For instance, track the performance of a process from a step to another from one resource to another from one function to another.

Of course, to get that unique integrated set of views, one needs the frame that holds them together exposing placeholders when the components have not been represented yet. Do the current EA frameworks achieve that?

EA, as a practice, needs to roadmap to change in the Enterprise, facilitate the alignment of the structure to changing ends.

EA is used for many and various purposes, in fact as many as stakeholders. Each would see a part of EA, a plan of concern to own work, but integrated in the whole.

Adrian Grigoriu is an executive consultant in Enterprise Architecture now living in Sydney, Australia. Shortlisted for the Computer Weekly IT Industry blogger of the year 2011. Former Head of Architecture and EA at OFCOM, the Agency providing regulation to frequency spectrum utilization and broadcasting industry in the United Kingdom. Previously Chief Architect of TMForum, the standards organization providing Frameworx, the Integrated Business Architecture framework for the telecommunications and digital media industries. Adrian also is an Executive Enterprise Strategy and Architecture Consultant and author of "An Enterprise Architecture Development Framework" book available on Amazon and Kindle at Trafford and elsewhere. Reviews of the book are available from BPTrends and the Angry Architect. Here is a short Enterprise Architecture animated slideshow summarising his view. Adrian also offers an EA and business architecture training course on-demand, based on the book. You may get in touch at grigoriu@hotmail.co.uk. His website.

Popular White Paper On This Topic

9 Comments

Adrian:
What you have described is the real world of architecture. As noted, few frameworks have come close to describing what needs to be done to ensure integration across the enterprise. When we were developing the latest version of DoDAF, we described 'federation' in much the way you describe integration here. Architectures are supposed to seamlessly 'connect' to the architectural views on their 'edge' but few do as solutions are created from a variety of viewpoints, using a variety of tools, and a variety of data.

Our concept of federation and tiered responsibility said that it was the architect's job in creating the views to seek out and utilize data from the edges to make those edges seamless, and capable of data transfer and use. What we did not say, however, was that there needs to be an enterprise view--a schematic of what the whole enterprise looks like at its highest levels--so that the lower level solution architectiures had some way to tie to the enterprise.

At DoD, the closest thing we have to an EA at that level is the GIG Architecture. By tying solutions to the GIG (as they are supposed to be anyway) it is possible to see how integration occurs at the higher levels--sometimes if they only logicall exist. I did an architecture a couple of years ago for an Air Force organization where their next higher level had not views, but the Air Force did, and we could create some dotted lines through their intermediate organization to the Air Force and to the GIG. Over time, tying to such a blueprint creates the information structures needed to understand the EA level concepts.
best regards
John T

John,
Yes, this is the real world of architecture; we need the EA framework and guidelines that connect (federates as you put it) all your architectures, even the pieces to come, in a cohesive whole. What you do with it is another matter. I usually start with an one page business architecture (GIG in your case) built on Value Chains and then drill down and associate responsibilities/ownership for each artefact design. It's all in in my EA book. They have constraints though, a place to plug back in. But I gave up preaching: no one is listening any longer. Too many agendas.
Adrian

Yeah definitely very
improving for the people it was pleasant to read about this good topic! If you need to get a great job firstofall you need resume services. Study and don't forget - if you have to work and study at the same time, there arehotshots who are ready to help you with your resume when you under time burden and looking for a great job.

Hi Adrian,
First of all, thank you for the nice blog. I've a question on selecting viewpoints for enterprise architecture. In solution architecture space, its easy to identify viewpoints, because the stakeholders needs are well defined and hence developing views is easy. But in EA, there could be 'hidden' stakeholders, who may not be come to forefront at initial stages. So, my question is how can we identify all the stakeholders and stakeholder viewpoints in the EA cycle?

Hi Adrian,
First of all, thank you for the nice blog. I've a question on selecting viewpoints for enterprise architecture. In solution architecture space, its easy to identify viewpoints, because the stakeholders needs are well defined and hence developing views is easy. But in EA, there could be 'hidden' stakeholders, who may not be come to forefront at initial stages. So, my question is how can we identify all the stakeholders and stakeholder viewpoints in the EA cycle?

Jagatesh,
After you build the key views you simply have to poll the audience and see what they would like done first or at all. Every organization is different. And there are an unlimited number of views: printing landscape, data center view, call center view, user equipment, real estate ,financial views...
Adrian

This is the perfect blog for anyone who wants to know about this topic. You know so much its almost hard to argue with you (not that I really would want…HaHa). You definitely put a new spin on a subject thats been written about for years. Great stuff, just great!
______________________________
resume writing services

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.