Oracle – An Architecture Treasure-trove

Anyone following the strategic acquisitions by Oracle the last few years can see a very clear trend: Oracle is amassing a treasure-trove of business applications that are powerful, interoperable, and valuable to mission delivery.

Most recently, Oracle snapped up Sun for $7.38 billion, right from under the clutches of IBM!

Oracle with $22.4 billion in revenue in 2008 and 55% of license revenue generated overseas “is the world’s largest business software company, with more than 320,000 customers—including 100 of the Fortune 100—representing a variety of sizes and industries in more than 145 countries around the globe.”(

Oracle’s roots are as a premiere database company. However, since 2004, they made more than 50 acquisitions in calculated business areas.

The Wall Street Journal, 21 April 2009, identifies some of these notable buys:

2004—PeopleSoft for human resources and financial management.

2005—Siebel for customer relationship management.

2007—Hyperion Solutions for business intelligence.

2008—BEA Systems for infrastructure management.

2009—Sun Microsystems for software, servers, and storage devices.

Oracle has been able to acquire companies with operating-profit margins of 10% and within six months expand those margins to 40%.”

With the recent purchase of Sun, Oracle is gaining control of critical open-source software such as Java programming technology, Solaris operating system, and MySQL database.

According to Forrester Research, “Forty-six percent of businesses plan to deploy open-source software in 2009.” Oracle can now provide an important service in product support and updates for this. (Wall Street Journal, 22 April 2009)

In addition, Oracle also provides various middleware to integrate business applications and automate processes.

From databases to end-user applications, from service-oriented architecture to infrastructure management, from content management to business intelligence, Oracle has put together a broad impressive lineup. Of course, this is NOT an endorsement for Oracle (as other companies may have as good or even better solutions), but rather an acknowledgement of Mr. Ellison’s keen architecture strategy that is building his company competitively and his product offering compellingly. Ellison is transforming the company from a successful single brand that was at risk of becoming commoditized to a multi-faceted brand with synergies among its various lines of business and products.

Some lessons for enterprise architects and CIOs: Build your product lineup, create synergies, uniformly brand it, and be number one or number two in every product category that you’re in (as Jack Welch famously advised) and grow, grow, grow!

>Information Exchange Matrix and Enterprise Architecture


The Information Exchange Matrix (IEM) —a.k.a. OV-3 from the Department of Defense Architecture Framework (DODAF)—identifies the information exchanged between entities and the relevant attributes of that exchange such as source, destination, type of information, trigger for the exchange, media, frequency, quality (timeliness, completeness, etc.), quantity, and security.

Major characteristics include:

  • Information requirements: IEMs document information exchange requirements for the enterprise. They identify who is exchanging what information to whom, when, why, where and how. The IEM describes the flow of information in the organization.
  • Business Process Driven: IEMs are driven by business processes and activities and demonstrate what information is required to perform the mission-business functions of the organization.
  • Major Information Exchanges: IEMs are usually not comprehensive, but rather capture the major information flows that support the mission-business.

In User-centric EA, information exchange matrixes are one of the most critical products in the architecture. By knowing and understanding the information required by the enterprise (as identified in the IEM), architects are able to do the following:

  • Identify the systems that are providing information required by users.
  • Identify systems that are providing information that is not (or is no longer) required by users.
  • Determine which systems are redundant (i.e. meeting identical requirements).
  • Determine where there are system gaps (i.e. no system is providing the requisite information) .
  • Plan new technology solutions to meet new or changed information requirements.
  • Develop an environment conducive to information sharing by distinguishing which information exchanges must be on a need to know basis (secure) and where greater openness and sharing can occur.
  • Pinpoint what business processes should be reengineered or improved to better make use of available information and meet performance outcomes.

IEMs must have user participation. They cannot just be reversed engineered from existing systems, since that will only tell what information is currently being provided (and what information should be provided). Also, pulling the IEM information from systems does not address existing manual information exchanges that could very possibly be automated going forward.