The State of Enterprise Architecture
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:
- Create the vision
- Provide direction and oversight
- Hit key areas of business processes/services, enterprise metadata, infrastructure, and security
- Have fiscal responsibility
- Perform research and development to harness emerging technologies
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
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.
The value of enterprise architecture
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>
@chan and @Peter
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.