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

On current and future Enterprise Architecture

user-pic
Vote 0 Votes
Philip Allega of Gartner replied on my blog with "Future state first current state last" to the position stood last week on the debate on current and future EA. Thanks Philip, I'll take the challenge since this is an old debate for many. 

The emphasis in his latest blog moved to the priority of the future state rather than doubting the current EA worthiness and stopping it as in the previous.

I'll summarise my position, upfront, for brevity, before going into explanations.

I'll say that a realistic Enterprise vision must be planned from the current state. 

The vision remains a day dream, unachievable if the gap analysis necessary to plan the Enterprise transformation may be not performed because the current state is not documented. Mind you, a reasonable description is all right for there are many iterations. 

The vision itself must be based on the current state. 

The target Enterprise state must take into consideration not only vision but also the current problems which are documented by the current EA. 

Tabula rasa (rather than rosa), i.e. discarding the current state, is not, in practice, an option for any business management in performing the Enterprise transformation to achieve Vision.

EA is more than vision implementation. It is about complexity management, alignment... To realise all these you need the current EA.

Now, to detail.

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... All this is based on the current EA.

The target state is designed with the idea of fixing both the current state issues and achieving the vision. You need the current EA to fix the current problems not only to achieve Vision.

if you plan to improve your home, you first take stock of what you have (like size, location...). And then you build your "vision" on that because that tells you what is possible, what you can afford, what the land permits..., unless of course, you wish to demolish what you already have. You won't plan a shopping mall on a little cabin in the mountains.

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

About the failed EA example. It's rare when EA succeeds, given its IT orientation alone. Nevertheless, when transforming the Enterprise you have to consider all change, not duplication reduction... or vision in isolation.  

I also cited research that states that delayed gratification in children is a characteristic of later achievers, to support a position of starting with the current state to achieve vision. 

True, you can have brave visions if you don't know yourself or remember who you are.

Philip also liked this quote:

"Things are the way they are today because of the decisions we have made in the past. But just because they are that way today, does not dictate the future of how things will be tomorrow."

This really says, if you accept it as true, that one can change things, not that one may ignore the initial state. And that your past visions are now your current state, a truism. It is high time to document this state, once for all, rather than live in the future.

And not least EA is about Architecture. You use it, not only to achieve a target, but for instance to understand the Enterprise structure and operation.  

To reply to a related comment, Deb's.

"My views are very strong on this Phil - current state is business-as-usual for every person in the organisation EXCEPT the archietcts. Their role is to collect the current state inforamtion that is a reflection of the future state being defined.

The minute any EA team starts the accept that they are responsible for documenting the current state then they are on a slippery slide down to oblivion. 

Every business manager should understand, document and update their processes, infroamtion and solutions. Every IT manager should understand, document and update their technology. How can they manage if they have no idea what they are managing? What arrogance that they think they can delegate this accountability and responability to the architects?

My advice make them all accountable for the current state and get on with strategy and future state!"

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, otherwise there would not be much need for an architecture.

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; the EA architect will integrate the these parts.

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

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

After all, EA is Architecture, a blueprint that is used by stakeholders in different ways - operational, tactical, strategical- not only to realise Vision. For that you need the current EA before anything else.

5 Comments

| Leave a comment
user-pic

This post addresses several very important topics. I’d like to comment only one of them “Thus, the vision itself must be based on the current state?.

Why we have a vision? Because we are not satisfied with what we have. Is this because we really do not have something or we do not know that we do have this something? Or because we saw something somewhere and understood we need this?
In the last case, the vision is NOT based on the current state. Moreover, real vision is not necessary tightly coupled but rather loosely-coupled with the current state.

It is totally another understanding that no move to the vision can avoid clear knowledge of the current state. In this line of logic, any movement to the vision is “based on the current state? but not necessary the vision itself. The clear knowledge about the current state assumes that the current state is fully documented. In my experience, the documentation of the current state of EA of mid-to-large size organisation took up to 3 months work from the team of 5 Enterprise Architects. I agree with Adrian in this.

user-pic

Adrian,

It's apparent that we will agree to disagree. A gem in my posting was that "you will never get to the future state"; but, that does not make the planning exercise worthless. Indeed, it sets a marker to determine where you want to be, even if it's further away from you getting there.

In my blog about "Applying EA to Your Life", I discussed a friend who has a grand vision but a very challenging current state. In fact, he learned that he had a number of current state obstacles that lengthened the time to close the gap.

Knowing where you are is, indeed, helpful. But, you should know the reason why you are doing something to fix, extend, correct, or eliminate some portion of your current state. Basing what you can do because of where you are does not set a target that is what you need. I still contend that any attempt to do anything to your current state without a properly created vision will both limit what you can do and not identify what you should do.

The scientific study I quoted also proved that, by considering where you are BEFORE considering where you want to be you will LIMIT your future target state. I'm not quite so certain I understand your reference as it's not explicitly focused upon making decisions based upon an unfettered future state versus creating a future based upon today's limitations.

Recently, I spoke with a client who was struggling with multiple CRM solutions across different divisions. The IT leadership team asked me what they could do to architect a solution that reduced the number of systems, reduced complexity of the IT portfolio and reduced overall costs. I asked, "How will this help your business?" They did not know the answer.

We stepped back and they created a future state "business context" package with their IT investment team (think business and IT leaders together). The result was a discovery that the CRM solutions, and their associated costs, were in line with the desired future of the business - the work that IT was engaged in had no value for the future of the business. Indeed, they were surprised to learn that there was little work being undertaken against the most important future priorities of the business - this was rectified quickly.

Without a future state to consider, any work upon the current state presupposes the answer.

Without a uncluttered future vision, the choices of what to do next will be limited.

As you, and others, have shared, current state analysis can lead to assumptions about the target state. I would contend that, while this identified some useful work, another result may have directed work efforts in another direction had an unfettered target state been created. Unfortunately, we won't know until a proper vision is created and vetted against the current state.

I don't recall if I noted that this feel counter-intuitive, but your response proves that it feels counter-intuitive to you.

I don't have the data to prove this, but my hypothesis is that current-state focused EA efforts always have some sort of implicit future-state considerations that help them vet what they will do, or won't do, to move them away from their current state.

Survey's at Gartner's EA Summits in 2010 indicated that the majority of EA practitioners continue to focus upon the technology artchitecture WITHOUT a documented "business context" that links there EA advice to the desired future state of the business. It's a shame that we have this state of affairs in the practive of EA, but it does not surprise me that EA practitioners are not creating proper future visions. The reasons range from the beliefs you have shared to outright fear to engage business leaders.

My experience as a practitioner and long time coach and analyst in EA supports the Gartner contention that it's "Future State First, Current State Last"; but, I am also aware that this feels contentious to others.

I do appreciate the opportunity to hear your opinions and the perspectives of others on this matter. I look forward to continuing to hear your perspectives.

Philip

Hi Phillip

I'm not really sure how to interpret these comments .. may I ask for a different explanation of them?

1. Without a future state to consider, any work upon the current state presupposes the answer.

2. Without a uncluttered future vision, the choices of what to do next will be limited.

regards
Gregory

user-pic

Late to the party... This is interesting and has been useful in determining a course within my own organization. I believe the tasks are parallel activities by different points of view; division/department leadership providing future state and departmental subordinates (where the rubber meets the road) providing current state. Gap analysis is the integration of the 2; culminating in a roadmap to get from point 'a' to point 'b'.

Also, the future state is not attainable until it is adopted into the operational model. The operational model includes rewards for meeting performance objectives. Until then, it has no form for integration.

Thank you for your thoughts. - Phil

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