InfoQ

News

The State of Enterprise Architecture

Posted by Steven Robbins on May 08, 2008

Community
Architecture
Topics
Leadership ,
Funding ,
Enterprise Architecture
Tags
Business/IT Alignment ,
Best Practices ,
Culture Change ,
Organizational Patterns
As organizations continue to grow their IT investments (bought, borrowed, or built) and concepts like Business Process Management (BPM) and Service Oriented Architecture (SOA) become more common, the role of Enterprise Architecture (EA) has become more common. Recently, David Linthicum, Mike Kavis, and Alan Inglis each talked about what they see with respect to EA in the industry.

Linthicum asked the question: Should we continue to invest in EA? He pointed out the typical approach to Enterprise Architecture in Global 2000 companies as:
[F]or most of the Global 2000 there is a lone architect, with a couple of staffers, that has no budgetary nor referential authority, thus no results. You can't "influence" your way to success, you have to have some kind of hammer drop on somebody's head if they don't follow the core architectural principles…it's called governance. Thus, there are groups of people drawing very nice paychecks that don't add value to IT, or the business, and don't have to deliver tangible results.
Linthicum's pointed out that he isn't coming down on the architects themselves regarding this specific issue. Instead, he stated that it is the organizations continued focus on tactical projects in IT while only paying lip service to real strategic (i.e., enterprise architectural) that contribute to the current state of affairs in EA. He did hold enterprise architects accountable for what they do produce even within this context. He said that the two main issues with architects in this role are that they can't measure or quantify the issues their organization currently has and that many of the architects fear change. Some of the measurements needed by enterprise architects are cost inefficiencies in the infrastructure, quantifiable value of technology reuse, and the value of organizational agility.

Linthicum answered his own question by stating "So, I say, if your enterprise architecture efforts are not effective, don't continue to invest in them. That is, until you get serious about doing architecture, and are willing to carefully measure the value to the business."

Mike Kavis shared information from a presentation he gave to management within his organization on the value of Enterprise Architecture. Key points in the presentation were: defining EA, the role of the chief architect, and the value of having EA and an EA group. In his slides, Kavis described what the EA team should focus on:
  1. Create the vision
  2. Provide direction and oversight
  3. Hit key areas of business processes/services, enterprise metadata, infrastructure, and security
  4. Have fiscal responsibility
  5. Perform research and development to harness emerging technologies
Mike's presentation pointed out some of the good practices inside of EA. He also talked recently about the downside of EA by describing 10 reasons enterprise initiatives fail. Of the ten reasons Kavis listed, only one is technology related: "Lack of technical knowledge." The rest are focused on organizational and people issues. One of the biggest of these issues is "Underestimating or ignoring the impact of change":
People need to know WIIFM (what's in it for me). Resistance to change can kill any project. Your initiative must have a champion who carries a lot of clout. The leadership, lead technicians, project managers, and all of the visible people in these projects must be positive forces and constantly promote the vision and the future state. ...People will feed on the attitudes of those leading the initiatives. You must address resistance head on and address people's needs to help them turn the corner. For those who just refuse to buy in and become roadblocks, show them the door!

Commenting on the list, Mike Walker added another item to Kavis' list that echoed Linthicum's discussions: Teeth in the process. That is, the enterprise needs to have governance with authority to enforce the principles. Without those teeth, governance is simple a list of things an organization ought to do instead of the things they have to do.

Alan Inglis commented on the state of EA in Europe as compared to the US. Echoing Linthicum's thoughts on "drawing nice paychecks" without adding value to IT, Alan hypothesized that the recent upsurge in funding for American EA efforts may be what is hampering them.

If you have millions of dollars and years to deliver then what pressure is there to be pragmatic? This has meant that the dominant approaches to Enterprise Architecture are Big Architecture Up Front approaches. Where architecture has had less acceptance and less money, we have had to evolve alternative ways of achieving our goals. We have had to develop creative approaches to making our money go further.
Inglis seemed to be pointing out that European EA efforts are succeeding strategically due to their requirement to execute tactically because of funding.  It seems that the "curse of plenty" affects IT across the board.
EA is a management competency of strategy lifeycle management by Chan Cheah Posted May 8, 2008 10:29 PM
The value of enterprise architecture by Peter Evans-Greenwood Posted May 9, 2008 1:38 AM
@chan and @Peter by Richard Henderson Posted May 14, 2008 4:29 AM
  1. The missed understanding of EA is that it is a management competency. EA is not about engaging highly paid specialised people who have to justify their value worth. EA is an emerging sub-discipline in the practice of organisation project management for implementing strategies. More specifically, EA is a new aspect of service quality management in project and program management - it assures the systemic design/ architecture of interoperating people, process and information system capabilities can explicitly shape strategic services to result in outcomes that are the targeted achievements of planned portfolio strategies. In this new light, EA is becoming a new part of corporate and divisional strategy planning and implementation management know-how.


    EA had matured in the contexts of system modelling and process definitions especially in information systems design and integration with business information, process and knowledge management reengineering perspectives. The practice has spread as a result of embracing SoA technologies. The scope of current EA capability maturity is still at the operational level, where EA usefulness/value is about improving operational workflows through digital service provisioning and management and people capability re-development for achieving cost efficiency and/or product/service differentiation.


    Because of this ICT origin, the business impact and value delivery of EA are driven bottom up by ICT design standards and product evolutions. It is no brainer that the practice is indeed driven and dominated by people with ICT know-how, many who are already advising strategy and project management personnel in areas already indicated by Kavis, eg creating vision, direction and oversight, changing business information, infrastructures and practices, engaging fiscal governance, etc. Kavis’s list of the 10 reasons why enterprise initiatives fail also reveals the risk of engaging architects with no or lacking substantiated enterprise strategy planning and implementation experience and formal accreditation. In today’s business, the influence of globalisation has dispersed the value chains of organisations across different locations, adding another complexity of multi-site in strategy life-cycle management.


    Perhaps one solution is not to continue having and depending on more EA specialists, but to extend the capabilities of strategists and organisational project teams to include EA skills. With this skill competency, strategists can continue to be accountable for delivering corporate and divisional strategies, and assuring organisational project teams to be responsible for accomplishing the delegated components of these strategies. Hence, introducing and leveraging EA into enterprise practice is eventually becoming a model of knowledge management reengineering.


    The smarter organisations would shift towards investing in developing sustainable EA knowledge management strategies where people can be continuously re-skilled and supported by both in-house and open community EA knowledge and process standards and system tools. With the existing availability of EA knowledge and practice standards, half the work is already done and the remaining effort is about how to rationalise the number of architects and leverage the best to develop an effective EA knowledge management solution that is part of strategy lifecycle management. Inevitably, the current fad of Chief Architects and their support teams will be short-lived.

  2. Back to top

    The value of enterprise architecture

    May 9, 2008 1:38 AM by Peter Evans-Greenwood

    If we're honest with ourselves, then we need realize that the business sees zero value in enterprise architecture (and IT in general): it's a cost center. Business invests in web presences, ERP, CRM ... not because they want to, but because they are forced too. They'd rather spend money on creating value by designing new products, improving production ... Enterprise Architecture is in a worse situation than the rest of IT as it's a planning function, so it's seen as overhead on a cost center. Most EA groups make matters worse by defining themselves as <em>the department that says no</em>, blocking that majority of business initiatives as they're not "strategically aligned" or presenting major application upgrades/installs as the solution to every problem. Want to support new customer channels? Upgrade to the latest CRM at great expense with a long project.


    If we want business to value the EA function then we need to a few pages from a customer service manual; our job is to find ways to solve the customer's problem rather than say no, we can't do that. Want to support new customer channels? In the short term we can do something tactical to trial the idea with key customers. We might even steal an idea from GMail and create invitations to shape demand, handing them out to high performing sales reps as a reward. Then we can evolve the solution over a number of iterations as we work toward the final application deployment. Solve a chunk of the customers problem quickly, and then work with them to reach the final solution.


    EA groups need to get out of the office, bury themselves in the business and help them solve problems. Too often it seems that the EA team's only reason to exist is to support governance and method.


    Slides to this effect at SlideShare.
    <div style="width:425px;text-align:left" id="__ss_395364"><object style="margin:0px" width="425" height="355"><param name="movie" value="http://static.slideshare.net/swf/ssplayer2.swf?doc=thevalueineav01cmp-1210291222731475-9"/><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed src="http://static.slideshare.net/swf/ssplayer2.swf?doc=thevalueineav01cmp-1210291222731475-9" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="font-size:11px;font-family:tahoma,arial;height:26px;padding-top:2px;"><img src="http://static.slideshare.net/swf/logo_embd.png" style="border:0px none;margin-bottom:-5px" alt="SlideShare"/> | View | Upload your own</div></div>


    r.


    PEG

  3. Back to top

    @chan and @Peter

    May 14, 2008 4:29 AM by Richard Henderson

    @chan: Management consultant by any chance? Dear me. Nul points.

    @Peter: Yes.

    Specifically, EA must demonstrate value i.e. be engaged with the business at all levels.

    It is a technical competency (sorry Chan) requiring real architecture analysis and communication skills, based on relevant technical wisdom.

    The skill-set is rare. Becoming rarer for some reason.

    The value is profound (consider the value of doubling the efficiency of the entire development and operational lifecycle).

    Therefore doing EA right is a significant value-add. Doing it wrong is a complete waste of time and money.

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.