The Art of Architecture Transformation

Part of the Oracle Experiences in Enterprise Architecture article series

Enterprise architects (EAs) are sometimes asked to instigate a complete IT transformation-an end-to-end renovation of corporate business systems. One of the reasons companies undertake these transformative projects is because their IT operating structures are outdated. They may have created stovepipe information systems that function well as independent entities but don't work together in a cohesive way. Or perhaps the IT transformation project is driven by an aging hardware infrastructure that is wasteful, inefficient, or doesn't reflect best practices for data center management.

Whatever the reason, in order to truly transform the business, IT and business leaders must come together to define an Enterprise Strategy. IT must understand what the business needs, and then offer prescriptive guidance about how to architect, plan, build, and operate an updated technology environment.

Doing this effectively, and with credibility, is part art, part science. The science of EA is represented in the methodologies, frameworks, reference architectures, and best practices that architects use to structure the development effort. But EA is also an art that entails subjective considerations related to understanding the corporate culture, assessing the impact of industry regulations, gauging management's tolerance for risk, and a multitude of other issues.

At the outset of any Architecture Transformation project, determine if you are confronting a problem that is worth solving. Some EAs make this determination by assessing the "Real/Win/Worth" factors. In other words, is the problem genuine, is it solvable, and is it worth the trouble? To make these determinations, ask yourself the following questions:

• What does the business need to do that it can't do today? (In other words, what are you trying to achieve, and why?)
• What changes need to occur in order to achieve the stated business goals?
• Why are you confident this will work?
• How can you justify the necessary investment?
• Once the project is completed, what benefits will the organization enjoy?

Once you have identified the business problem and determined that it is worthwhile to proceed, put on your "science hat" to define the project. This is where a framework such as the Oracle Architecture Development Process (OADP) is useful. OADP divides the development of architecture into the steps of Architecture Vision, Current State Architecture, Future State Architecture, Strategic Roadmap, EA Governance and Business Case. It provides a practical approach to architecture transformation with prescriptive guidance to help you move forward in an iterative fashion, so you can focus on delivering results.

Business owners and stakeholders often make their decisions based on the expected payback. To get their buy in you need to be able to present demonstrable cost savings within a reasonable payback period for a prudent level of investment. One way to uncover these numbers is to analyze the impact of functional changes to specific business processes. How will they yield improved efficiencies in operations, customer service and other business domains? What is the impact of quicker response time, higher uptime levels, and overall improvements in quality of service?

Case in Point

A transformative architecture vision starts with a big idea, is aligned with a set of business challenges, includes both a technology and financial perspective, and is grounded in well defined architecture principles. The vision should be aligned with a real problem. In many of today's businesses, that problem centers around a desire to consolidate a sprawling IT infrastructure and adopt shared services.

Such was the case for one of Oracle's recent engagements involving a large financial services company that was rationalizing its application portfolio, adopting engineered systems and moving to a private cloud infrastructure for databases and middleware. This company had low average server utilization, hovering between 12 and 18 percent. Its multi-vendor IT environment lacked standards and was difficult to scale. After defining the current state and future state architecture, Oracle EAs defined an optimal server utilization target of 75 percent. We also laid out a unified, single vendor platform that would reduce complexity via standardized build operations. In our estimation, thousands of database servers and a highly complex storage infrastructure could be replaced by 120 Exadata platforms with standard, easily scalable configurations.

Many EAs have an easy time making technical assessments and recommendations. But when it comes to transformative projects-especially when they involve portfolio rationalization-you have to be prepared for pushback. Business users will resist when you tell them that they won't be using a familiar application that has automated their activities for the last ten years. System administrators won't understand when you tell them that don't need to provision storage like they used to. These are disruptive changes that must be backed by a solid architecture vision and a cohesive technical roadmap that reveals precisely when people will start realizing benefits.

Once the development process is underway, you need governance procedures to continually verify the value of the EA effort. Develop a clear case for measuring the organizational impact and provide a mechanism for reporting on that impact. Establish performance metrics that demonstrates the value and report on it frequently to key stakeholders. Continue to obtain buy-in from people who are impacted by the changes taking place by including them in business and enterprise architecture discussions.

Remember, successful EA projects are a blend of art and science. To be successful, you must measure the business impact of architecture transformation. Align your efforts with the predominant culture, and pay attention to the tolerance for risk and other financial realities that govern decisions of this scale. Fit your project within your organization's operational model, and always articulate the benefits awaiting users in the near future.

Additional Enterprise Architecture resources:

• Visit the Oracle Technology Network Enterprise Architecture Center
• Visit the Oracle Enterprise Architecture Blog
• Read more articles and white papers
• Download reference architectures
• Learn about Oracle EA Services
• Attend an EA event

About the Authors

Alan Levine is an enterprise architect with Oracle Corporation. 

Hank Margolis is a business architect with Oracle Corporation.