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.
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.