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

About Gartner's Philip Allega "Applying EA to your life"

user-pic
Vote 0 Votes
It is often said that "life imitates art".  According to Philip Allega of Gartner in "Applying EA to your life" we should apply  Enterprise Architecture techniques to plan our acts of life or achievements.  I sincerely hope we don't come to that, that is use TOGAF or a look alike to plot our lives.  

Since the dawn of time people established goals, assessed where they were and what they have to do and then worked on it. The good news is that they could do without EA, especially given its failure rate today. Otherwise we would not have reached our venerable ages and current positions by chance alone.

Then Philip says that "If you have started your EA program and your first activity is to document the current state, STOP NOW. Refocus your team on analysis of the business strategy and development of the future state architecture."

I hope this piece of advice was not meant to be taken literally. Imagine going to your CIO or senior manager telling him  that you have to stop the current state documentation work, now. 
If you catch him on a good day, he will probably explain to you that you need to discover your IT landscape to reduce the undesirable diversity in platforms and applications and introduce standardisation, eliminate unnecessary duplication, and costs as such, enable integration of various applications, document processes for improvement, establish a common vocabulary, an inventory of assets... And he is right, of course. Not that it is a matter of your choice, that is, as an Enterprise Architect you don't do the decision to stop working. 

Enterprise Architecture is not aimed at change alone and not all change is strategic in nature. EA is also about complexity management or aligning technology to business. And about many other things. But EA should be implemented in iterations where you analyse enough of as-is and to-be states to be able to deliver the goods in your scope. And there is no one final Enterprise state. What's target today is current tomorrow.

The target architecture cannot be established based on Vision alone. It is not practical or economically viable to start from tabula rasa each and every time you implement a new strategy. Competitors would be delighted though.

Questions arise, like how do I know how the future architecture looks like, without the current one, what do I do about the ERP system I just implemented and trained people in,  what do we do about the projects transforming the Enterprise as we speak... how do you do roadmapping, if you don't care the current system is SAP? I am sure there are more questions like this.

This approach incites to continuous revolution, rather than evolution with the high price to pay for such sudden and mountainous changes. Anyway, once you go through a first target architecture development, you'll have a current EA, right? Or should we just ignore the works done and start from scratch again at the next cycle?

Philip's comparison of the exercise of current architecture design with "naval gazing" is worth quoting though.

He wrote, with regard to his friend conundrum to built a new career, for which I have sympathy, that the turn around plan is "ambitious" and "the alternative scenarios we discussed were none too pleasant given where he's starting from". 
So Philip did consider the starting point.

I can also cite research that delayed gratification in children, that is first work and then achieve your goal, is a characteristic of later achievers. But then all these scientific observations, how reliable are they  ? Wasn't it said that a nine years old is mature enough to function in society? Or that frustrated children increase criminality later? Criminality seems to be high anyhow, but children may be illiterate as well now.

6 Comments

| Leave a comment

Hello Adrian

I basically agree with you. While I have been in ERP businesses, I have seen so many customers had spent so much amount of time, resource and money on creating to-be models hiring brilliant consultants.

Then, at the end of the day, management and people in organizations had reached a common understanding, that they are not capable of digesting those to-be models.

Thinking about challenging, evolutionary, feasible and practical passages has never been easy, rather painful, I reckon.

Adrian,

Thanks for the post and insights. I commented further on the importance of the Current/As-Is State on my blog:

http://leodesousa.ca/2010/08/do-you-need-to-create-an-as-is-state/

Thanks, Leo

Hey Adrian. I'm not from Gartner but have sat thru their usual EA pitch and believe their view is more a future state first which provides context and scope as part of the feedback loop into the current state. Oddly enough a systemic approach to problem solving. Pity this approach is not taken further though.

user-pic

Thanks Adrian, for sharing this with others. I know that this is controversial; but, I also know that it takes practitioners down a different path. I'd ask that you consider this blog:

http://blogs.gartner.com/philip-allega/2010/08/24/future-state-first-current-state-last/

And note a response from Deb Weiss, a chief architect from Australia.

I hope to hear more about your perspective that differs from mine, and my colleagues.

Philip

Philip,
Enterprise Architecture enables much more than vision implementation alone. It enables change, be it operational, tactical or strategical.
EA is also about complexity management, or simplification of the organically grown Enterprise, about aligning technology to deliver the operation the business really needs, about increasing business agility, enhancing understanding in the Enterprise workings...

For all that you need the current EA.
And you need the current EA to fix the current problems not only to achieve a Vision.

The target state is designed with the idea of fixing both the current state issues and achieving the vision.

if you plan to improve your home you first take stock of what you have (current state). And then you build your "vision" on what you currently have, what is possible, what you can afford, what the land permits..., unless of course, you wish to demolish what you already have and build no matter the issues.

Thus, the vision itself must be based on the current state.

I could also cite research that delayed gratification in children is a characteristic of later achievers, in support of a position of fixing the current state before achieving vision.
http://www.sciencemag.org/cgi/content/short/244/4907/933


I respond to Deb, as well, on Philip's blog.
Deb,
It is common sense that the business is documented by stakeholders, the very people who own the work and know most about the business. And indeed, it would be unwise to do otherwise. But that work is mostly not suitable "as-is" for integration in EA.

It is the task of the EA architect to establish the framework in which all the stakeholders' parts fit in, to specify how the EA parts look like to fit the whole, what are the missing parts, what are the design constraints, architecture principles, what are the components of EA that have to be re-used by all stakeholders, how to navigate the EA whole.
The current EA (re-)work would be done by stakeholders so that they take into account all these and deliver to the same standards.

Current EA is about every stakeholder documenting own work consistently to be able to link it to the rest of Enterprise parts in a coherent whole so that anyone else can navigate it.

To paraphrase you, I would say that an EA architect would be indeed arrogant, not to accept the duty to model the current EA.

user-pic

This EA stuff is getting to totally out of control.

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

Blogs

ADVERTISEMENT