As the discipline of enterprise architecture continues to evolve, the challenges of the practice of enterprise architecture remain. Many organizations struggle with accepting the need for and value of enterprise architecture as an enabler to data management success
Consider the supposed purpose of Enterprise Architecture (EA): “The Enterprise Architect connects the IT Organization to business goals” as defined by Van Meter and Brown in The Enterprise Architect. Then consider the general IT budget – anticipated by one respected research organization to hit something close to $1.5 trillion. Put those two facts together. Perhaps Enterprise Architecture could be the driving force of the IT function, supporting enterprise data management, and enabling more effective processes while ensuring reduced costs or at least slower escalation of those expenses.
Well, perhaps it is – but experience says otherwise, based on a couple of data points. First, examine commentary from a couple of distinguished witnesses: Ivar Jacobson observes that “Most EA Initiatives failed.” “My guess would be that 90% never really resulted in anything useful.” Allen Brown, President and CEO of the Open Group, suggests the “profession” of Enterprise Architecture is in its infancy, “It’s a new area and a new profession,” he says. As Jon Brodkin stated, “We’re looking at how we can actually address enterprise architects as we would a profession like legal, accounting or building architects. We’re taking baby steps at the moment”.
Reality of Enterprise Architecture (EA)
In reality … Enterprise Architecture is a discipline that hasn’t really made it to the big time. If that’s the case, what are the causes? Is EA a rocket that hasn’t got off the launch pad, or a firework that has fizzled? It seems that it’s the former. Some more simple data points:
An informal survey of salaries for Enterprise Architects seems to suggest that the position commands relatively high rates and organizations expect EA professionals to have definite skills and qualifications.
Although there are many products available to support EA or its component disciplines (business architecture, technology architecture, data architecture, infrastructure architecture), consolidation is usually an indication that a technology is about to become mainstream.
So, EA as a combined discipline could be poised to come off the launch pad, but hasn’t made it yet. What are the delaying factors? The problem seems to be that once past the one-minute elevator pitch, enterprise architects have trouble saying what they do, and how it benefits the enterprise.
The fundamental question is “how will EA make a sustainable and demonstrable contribution to enterprise profitability (or to whatever metric is fundamental to the operation)?” Answers will depend on your perspective on the EA role. One of the broadest perspectives is that of John Zachman who argues for the management of a set of architectures that, when complete, would describe every aspect of the enterprise. A much narrower view argues that the essence of EA is the modeling of technology choices to support business strategy, which is essentially none of the architect’s business. It really does not depend on an architect’s place on the spectrum, it is their answer to the basic question – “How do we know that an investment in EA will add more to revenue and reduce costs more than any competing investment?”
EA and Return on Investment (ROI)
An issue related to ROI is that of deliverables. What are the products of Enterprise Architecture, and who cares? It can be a sobering exercise to map deliverables against its potential audience and try to figure out if the intended recipient could do without a cherished artifact! In a way this is a drill-down from the gross ROI question. It amounts to asking for models, plans, designs and architectures: “How does this add to the success of the person I’m providing it for?” One telling point as this issue is considered, is that there is no clear agreement as to what the “right” set of deliverables is, according to Goethals. It should, of course, be observed that EA may not be an end in itself, but a provider of inputs for processes such as Portfolio Management and Data Governance – which would legitimize different views of appropriate deliverables.
Given there is not a consensus about the deliverables it is not surprising that there is not a “standard” standard. In fact, there are many “standards”, although the one that perhaps should be core to all formal EA programs might be IEEE 1471 / ISO/IEC 42010:2007, which “addresses the activities of the creation, analysis and sustainment of architectures of software-intensive systems, and the recording of such architectures in terms of architectural descriptions.”
If one contemplates the issues of ROI, deliverables, and standards, it is easy to be reminded of a question that has concerns all those involved in EA programs: “How can we verify that enterprise architecture is good?” Reflection shows that it is a matter of advertising! What claims is the organization prepared to make about the EA program, and how will it be accountable for those claims? The problem, of course, is that there are too many variables, and it is impossible to establish the dependencies (or absence of dependency) between them. Can the architects state, “Our Enterprise Architecture will improve enterprise profitability by 11%?” Will it claim that “This Enterprise Architecture will provide a framework for hardware and software initiatives for the next five years?” These are easy assertions to make – but difficult to validate.
What can an Enterprise Architecture professional to do to earn respect? Most IT practitioners sense that EA is really important, and many believe that the role should be a natural stepping stone – perhaps the last stepping stone – before the CIO function. How can the enterprise share this high opinion of the profession and help its advancement?
Enterprise Architecture Trends
Without trying to be exhaustive, it is important to review some of the trends which continue to shape the IT landscape. Three categories that come to mind are external, social, and technological.
Some external forces to consider are macro-economic change, the related issue of globalization, and the associated issues of data governance and regulation. How can the EA function be positioned to steer the enterprise through the implied changes to staffing, applications, and constraints that happen from shifting supply and demand patterns, changing staffing approaches, and trans-border constraints on policy?
Three significant social factors influencing the IT function are the changing demographics of the workforce – in particular the “graying” of IT, the shift in control of the IT investment from the IT function to business management, and the increasing enterprise dependence on knowledge workers. How can the EA function ensure that the organization deals with the issues of a work force that is:
- Losing knowledge at the top end as senior staff retire, while becoming more dependent on knowledge to succeed.
- Increasingly demanding for specific IT capabilities, requiring role-specific distributed functionality and increased automation.
- Decreasingly “altruistic” in providing funding for information technology (cost-center centric, rather than the historical approach to centralized funding).
Some intertwined technological factors to consider are the adoption of service-oriented architectures, the emergence and sophistication of virtualization and the shift to a holistic approach to managing the information technology / business relationship. Possibly these trends have delayed the development of the EA “profession” as they invalidate architectures that had previously seemed well founded. How can EA provide a framework that adapts to technology changes in a sufficiently agile fashion to support the claim that EA delivers sustainable value?
Among the keys to unlock the EA puzzle are a narrative-based approach to understanding the relationship between IT and the enterprise (business), and an enterprise metadata repository.
A root cause of the failure of EA to “cross the chasm” into general acceptance is that it is still largely perceived as a discipline that benefits the CIO. When it truly becomes the facilitator of the dialog between the CIO and the CEO and the rest of the executive team then it will draw upon a much wider support base – and become mainstream. Of course, that may drive down salaries for all but a select few.
The metadata question is an interesting one. There seems to be a general acceptance that sustainable EA requires a metadata repository – but not much agreement about how deep and broad it should be. Metadata should encompass the business and process models typically held in an enterprise repository, the infrastructure and operations information located in a configuration management database, and the design models in an application repository. That argues for EA as an application pulling metadata from a federated metadata universe.
Conclusion
There’s nothing wrong, fundamentally, with the nature of enterprise architecture. The rocket is still on the launching pad. Some adjustments may be needed, but the engine is basically sound. Strap in, and get ready for blast-off!
