"Getting in front of new technologies and exploring the new business possibilities they bring is an architectural responsibility, but more importantly, it’s an opportunity for EA to bring value to the business."

Opening Statement

Enterprise architecture (EA) has become a mainstream activity in large or information-intensive organizations. Several years ago, Cutter IT Journal covered the emerging best practices in EA, and since then readers have requested that we check back to explore how things are evolving. What are EA programs focusing on in 2010 and beyond?

Well, what has changed since then? In the past few years, the industry has seen a lot of flux: outsourcing, "the cloud," Enterprise 2.0, Zachman Framework 2.0, TOGAF certification, a maturing definition of business architecture, the financial crisis, and new priorities. How have these affected EA in different organizations? What activities are they focused on now? What are the new issues?

Not surprisingly, the changes in EA reflect these changes in the industry, both in terms of new requirements -- and hence new approaches -- and in terms of lessons learned and improved best practices. One significant change has been the shift to outsourcing, which has affected architecture in several ways. First, how do we specify architecture and governance in an environment where operations and/or implementation are outsourced? What is the impact to the organization if the architecture itself is outsourced? How can that be managed to provide value to the enterprise?

One of the lessons learned is that architecture itself (or the EA program) has to be managed, and it has to continually deliver value. So what does it mean to manage EA? What information do we need to do that, and what does it mean to deliver value? I like to say, "Without metrics, you're just a guy with an opinion." We need metrics to demonstrate that EA is delivering value, but not the classic measure of ROI. Instead, we're talking about metrics in terms of savings, agility, flexibility, consistency, reliability, and so on. Plus, we need metrics to measure our own EA processes and apply continual improvement techniques to them. For example, when we can demonstrate the performance, effectiveness, and elapsed time of the architecture review process with hard numbers, projects teams can no longer object to participating.

Metrics, specifically service-level agreements (SLAs), will play an important role in the current shift in the industry toward cloud computing. EA has a prime opportunity to make this transition successful, rather than building up a new set of cloud-based application and technology silos. For example, with the cloud, business has a realistic option of sourcing capabilities from software as a service (SaaS) providers. But first, business architecture needs to ask some additional questions. Which capabilities are critical and core to the competitive position of the enterprise and which are commodity? What are the risks of outsourcing those capabilities?

Information architecture will be affected significantly by SaaS. With most applications today we control our own information, but with SaaS, we no longer control either the schema that defines the information or the actual data itself. This introduces additional questions: What data is it critical for us to control? How will we get that information from SaaS applications? How will we transform the SaaS data/schema to support our master data management strategy?

The cloud depends on the basic architectural principle of services, where there are three primary types of resources being provided as services: logic, platforms, and infrastructure. At the enterprise application level, we are concerned with the structure and implementation of the logic. For the cloud, we need to ask: "What services can we acquire from the cloud? How will these business and application services be integrated into composite applications to support business processes and user experience? What integration and performance implications will that have?

Obviously, infrastructure as a service (IaaS) and cloud technologies will have a major impact on an enterprise's technology and operations. To fully explore the architectural impacts of the cloud, we need to consider other aspects of architecture beyond the typical EA domains of business, information, application, and technology. To do so, it is helpful to have a broader view of enterprise architecture that expands the traditional concerns to include operational architecture and security architecture.

The cloud is one of many new technologies that EA will have to consider. Getting in front of new technologies and exploring the new business possibilities they bring is an architectural responsibility, but more importantly, it's an opportunity for EA to bring value to the business. New products, services, and technologies are changing traditional business processes and interactions into new collaborative experiences. But there is a major issue holding back the integration of these technologies together and with business processes. That is a lack of common semantics. How will these semantics be defined and described so that they can enhance the business or user experience, rather than increase complexity and integration costs? What are the new technologies and techniques? How should we account for them in our architecture? Whew ... so many questions.

Well, let's see what this month's authors have to say on these subjects. We start off this issue of Cutter IT Journal by looking back to lessons learned. First, Phillip Smith and Richard Harris from DTE Energy look back over the past eight or so years of their EA program, which today is well established and continually delivering value to the business and the entire enterprise. But it wasn't always easy. As the authors say, "To successfully develop and mature an EA practice, it takes principles and action plans coupled with collaboration, engagement, and leadership." One of the measures of a good organization is that it continually learns both from mistakes and successes, and DTE is working to accelerate what they are now doing through continuous improvement efforts, rooting out unnecessary redundancy and complexity. DTE leadership has given EA a clear mandate: in an economic crisis, its value proposition requires reducing enterprise complexity and improving holistic decision making. Take a look at how they're meeting this mandate. I'm sure you'll enjoy their insights and the way they distill their past experiences down to seven principles that help guide their efforts today.

Next, we look at how EA is dealing with the shift toward outsourcing with an article by Mohan Babu K of Infosys. He starts off by putting IT outsourcing into context and then positions EA within that context, both within the client and vendor organizations. This leads to several major challenges, including: loss of technical expertise due to sourcing, the need to coordinate multivendor scenarios, vendors lacking knowledge of organizational dynamics, vendors lacking subject matter and technology base expertise, and vendors lacking knowledge of organizational processes and terms. He examines each of these challenges in detail and suggests best practices for dealing with them.

Keeping with the theme of best practices, we turn next to an article by Cutter Senior Consultant Tushar Hazra. In the article, Hazra explains that EA metrics must be transparent, precise, and easy to use, and that the process used to collect the data for the metrics must support the practitioners. In other words, to enable continuous improvement, we need to have metrics, but the metrics must support the organization and processes, not add undue burden to them. He goes on to explore the value proposition of metrics and the significance of EA metrics in the enterprise. Finally, Hazra illustrates it all with a detailed case study from the financial services industry.

Then we shift gears a bit and look toward the future with the article about EA and cloud computing by Khaled Khan and Narendra Gangavarapu. As business becomes increasingly complex and competition increases, more and more enterprises are outsourcing functions, such as computing infrastructure, to cloud providers. In the cloud, many traditional EA components are shifted to the control of cloud providers. The interplay between the enterprise and the new characteristics of cloud computing need to be addressed in a new, cloud-aware EA. The authors' approach to the new architecture includes identifying how cloud computing affects EA in organizations and then addressing the cloud-based architectural components and activities in the EA. They observe that with cloud computing, "enterprises restructure their businesses and shift their focus in order to gain more agile and adaptive computing solutions." In a cloud-aware architecture, the business architecture may not change dramatically; however, the other domains -- information, application, and technology -- may change significantly depending on the aspects of the cloud that an enterprise uses. Khan and Gangavarapu reinforce these concepts with a case study from the healthcare industry that illustrates the new components of a cloud-aware EA. Finally, they summarize the challenges of the new architecture and offer some recommendations for dealing with them.

Last but not least, we turn to Enterprise 2.0, specifically semantics. In our final article, Cutter Senior Consultant Mitchell Ummel describes the fundamental shift in focus from an Internet of linked documents toward an Internet of linked, semantically precise data (the Semantic Web). The challenges and opportunities now are related to semantics -- or, rather, to addressing the lack of semantic definition that has plagued IT over the past decades and which manifests itself in application complexity and integration challenges. "We have also, by necessity, evolved an entire suite of semantic translation and interpretation layers built upon SOA, ESB, and ETL architectures, which in effect serves as `semantic duct tape,'" Ummel writes. He describes what he calls a "semantic enterprise architecture" built on three principles -- broadening the scope of enterprise architecture, considering semantically aware applications/data, and shortening the EA cycle time -- and tells us how we can start heading in that direction.

A common thread across all of these articles (and, incidentally, those from the March 2006 CITJ issue on enterprise architecture as well) is that EA has to deliver value to the enterprise. To do this, we need to take a look back at what has and hasn't worked and continually improve our processes, artifacts, governance, and so forth. And to do that, we need to be able to measure things. We can't stop and rest on our laurels, though, because technology continues to move forward: the cloud, Enterprise 2.0, semantics, and on and on. Enterprise architecture must be there to make sure we don't make the same mistakes with the new technologies that we did with the old -- or make new mistakes, for that matter. We also want to be there to demonstrate the new business opportunities that these advances present. Perhaps you'll recognize your enterprise or scenario in one or more of these articles and will get some ideas on the practices that will provide the most value to you. Read on!

ABOUT THE AUTHOR