EA Voices

<p><span style=”font-size: 11px; line-height: 19px;”>This posting wraps up our blog series on Enterprise Architecture implementation. In the series we described our experiences with implementing enterprise architecture, and how to be successful with that. We followed a step wise structure: Aim, Establish, and Execute. The structure and the postings that are part of this series are depicted in the figure below.</span></p><p><img alt=”Roadmap for success” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130508_EA-Roadmap-for-success-Wrap-up/Roadmap-for-success-wrap-up.png” style=”width: 676px; height: 422px;” title=”Roadmap for success: Final blog”/></p><h2>Roadmap for success: an overview</h2><p>Enterprise architecture can be a powerful tool, mostly if an organization has clear ideas and plans as to how enterprise architecture is going to deliver value to the organization. We described that enterprise architecture can benefit an organization in many ways, and that there are several approaches, the extremes being the top-down and bottom up approach. In a top-down approach enterprise architecture helps the organization plan for change on a more strategic level. In a bottom-up approach enterprise architecture can achieve better coordination and coherence among projects and application portfolios by leveraging enterprise architecture practices such as standards and principles. Whatever the approach is, enterprise architecture can never operate in isolation. enterprise architecture processes need to be explicitly aligned with other processes and frameworks in the organization. Often, implementing enterprise architecture is more about reusing, coordinating and leveraging existing processes, rather than introducing exclusively brand new ones. For the task of coordinating enterprise architecture work, the Architecture Board plays an important role. The way in which the architecture board should be organized and operate differs somewhat depending on the approach that the organization takes (<a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-top-down-versus-bottom-up-architecture/”>i.e. top-down or bottom-up</a>) describes all the details.</p><p><span style=”font-size: 11px; line-height: 19px;”>There are a number of Enterprise Architecture frameworks that could be used by an organization as a starting point for the organization specific enterprise architecture framework. These frameworks differ in scope and level of detail. We think the TOGAF standard (The Open Group Architecture Framework) is very complete, especially when combined with ArchiMate (also by the Open Group). ArchiMate can be used to model the Enterprise Architecture. Using ArchiMate, the viewpoints for various stakeholders as described in the TOGAF standard can be created. Independent of what framework an organization chooses it is of importance to tailor it to organization specifics. The framework should never be the goal in itself.</span></p><p><span style=”font-size: 11px; line-height: 19px;”>In the establish phase we covered a number of aspects such as project based implementation, how to <a href=”http://www.bizzdesign.com/blog/enterprise-architecture-roadmap-for-success-establish-an-enterprise-architecture-team/”>establish the team</a>, <a href=”http://www.bizzdesign.com/blog/enterprise-architecture-roadmap-for-success-tooling/”>what tools</a>(e.g. modeling tools) to use, and whether or not to use <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-consultants/”>consultants</a> to assist in the establishment of the enterprise architecture practice in the organization. Very important is, especially since the word enterprise architecture often comes with humongous expectations, to make sure that enterprise architecture implementation is broken up into pieces that the organization can absorb. We talk rather about evolution of the enterprise architecture practice, where an organization builds the enterprise architecture practice from the situation today, gradually introducing more enterprise architecture tasks and expanding scope and footprint. This approach lets the organizations enterprise architecture maturity grow steadily.</span></p><p>So trying to boil the ocean often does not prove to be a successful strategy for enterprise architecture implementation, following a sustainable growth path does.I<span style=”font-size: 11px; line-height: 19px;”>n the last section of the series we covered concrete aspects of doing EA, such as defining <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-architecture-principles-and-models/”>architecture principles and modeling</a>, <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-governing-projects/”>project governance</a>, and <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-capability-based-planning/”>capability base planning</a>.</span></p><h2>Learn more</h2><p>We think we touched upon important aspects of enterprise architecture implementation throughout this series. Of course there is a lot more to learn about Enterprise Architecture, implementation, modeling etc. BiZZdesign offers a number of courses on these subjects, for example training and certification in TOGAF and ArchiMate. Please see our web site for more information and dates. Also, we frequently run webinars on enterprise architecture and other topics in the Business Design field. Dates and more information can also be found on our website: <a href=”http://www.bizzdesign.com”>www.bizzdesign.com.</a></p><h2>Contact us</h2><p>If you’d like to know more, please contact the authors directly at <a href=”http://b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a href=”http://s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. </p>

 

Application portfolio management

Application proliferation/sprawl

Application Rationalisation/Reduction

These are phrases that are so often used within IT. The latter normally used in the context of an ill-defined goal that sits on top of an assumption that there are far too many apps and if only we could get the number down everything would be better.

The goal is often talked about and not actioned, when it is actioned it often doesn’t meet the expectations or flimsy, arbitrary targets that have been set.

If you have heard the phrases used above, if they are perhaps phrases that you use yourself then I think its worth asking yourself one question:

 

Do the users who get the value from the information system foot the bill for their use of the information system?

 

If the answer to this question is no (and there are a lot of orgs where it will be) then good luck!

If the answer to the question is no then you have found yourself in a situation where someone (it might even be you) has created and maintained a set of circumstances where there is a fundamental conflict between two actors in your organisation. 1) the users and 2) IT, because the decoupling of the realisation of value and the cost of delivering that value means one party feels only gain whilst the other feels only pain.

You will always have an uphill struggle to rationalise application portfolios as long as your user only experiences the positives of the application. Imagine persuading a drug addict that he needs to reduce his consumption because its really killing your bank balance paying for his habit. 

You need to re-couple the value cost relationship. One way of coupling value and cost back together and removing the conflict from the relationship is chargeback.

An impediment to implementing a chargeback mechanism is that it is often stated that chargeback is difficult. No its not, chances are its probably already happening elsewhere in your organisation and you don’t even know it. And you know what? Chargeback is getting easier and easier. As adoption of cloud services and the associated move to revenue spend increases, understanding the cost of usage gets easy. Even with on-premise applications the level and granularity of monitoring platforms today mean that it is achievable to trace usage back to cost. if you aren’t doing this then you obviously just don’t think its important enough, in which case you should stop whining about application proliferation and go and fight some other battle. 

Another perceived impediment to chargeback is a concern that a lack of ownership of cost will lead to even more applications. The ‘If marketing get to foot the bill for their apps we’ll end up with 5 different CRMs’ scenario.

Er, newsflash, if that was true you wouldn’t be talking about application rationalisation in the first place.

Application proliferation isn’t a symptom of uncontrolled spend.

Application proliferation and duplication of functionality is just a symptom of the fact that IT isn’t doing its job very well.

It is a symptom of:

– Poor engagement with your internal customers

– Lack of understanding of business need and the ability to offer effective solutions.

– Lack of appropriate change and architecture governance

If application proliferation and rationalisation is a hot or recurring topic then start by looking within, look at the type of relationships you perpetuate through inaction and challenge your assumptions about what might be the impediments to change. The biggest impediment to solving the problem will be your willingness to change the way you think of the problem.

Last week I had the pleasure to speak at the IRM-EAC conference in London about “How To Implement Enterprise Architecture Agile From Scratch”. Implementing Enterprise Architecture that way is actually my physical answer to my thoughts on Social Enterpr…

I wanted to share with all of you a new book called, “Reaching the Pinnacle: A Methodology of Business Understanding, Technology Planning, and Change (Implementing and Managing Enterprise Architecture)” by Sam Holcman. I’ve known and have worked with Sam Holcman…

In part 5 of “Memoirs of an Enterprise Architect” I discussed how to maximize value from the CMDB by integrating it with Troux.  In Part 6, I will continue discussing integration and how it relates to Big Data.
More Data…
Do you ever get overwhe…