SOA and Enterprise Architecture

I really liked Todd Biske's description of Service Oriented Architecture:

SOA doesn’t replace Enterprise Architecture, it’s simply one view of the enterprise. Today, one could argue that most organizations view the IT landscape as a collection of applications. Efforts like application rationalization or application portfolio management reinforce this notion. So, you could also say that today we have application oriented architectures. The unit of composition is the application. This isn’t flexible enough, as it is too coarsely defined. If we break these applications into smaller units, we now get to service oriented architecture, which I feel is a better way of describing things. Is it the only way? Certainly not.

Also, here are some links on the background of Enterprise Architecture that I think could offer some insight:

http://msdn2.microsoft.com/en-us/library/bb466232.aspx
http://www.enterprise-architecture.info/Images/Documents/Comparative_Survey_of_EA_Frameworks.pps
http://www.bptrends.com/publicationfiles/12-03 NL Enterprise Architectures.pdf
http://www.e-cio.org/lea_presentations/11_models_framework_files/frame.htm

Dynamically updating CSS Style attributes

Just having a little fun with CSS style attributes and came up with a demo page to demonstrate javascript dynamically changing the attributes of some text on the screen.

Click here to see.

The javascript/CSS that makes this happens is:

var DHTML = (document.getElementById || document.all || document.layers);

if (!DHTML) return;
var x = new getObj('divtext');

document.getElementById('divtext').innerHTML = text;
x.style.fontSize = fontsize;
x.style.color = color;
x.style.fontFamily = fontfamily;
x.style.fontStyle = fontstyle;
x.style.fontWeight = fontweight;
x.style.backgroundColor = backgroundcolor;

}

function getObj(name)
{
if (document.getElementById)
{
this.obj = document.getElementById(name);
this.style = document.getElementById(name).style;
}
else if (document.all)
{
this.obj = document.all[name];
this.style = document.all[name].style;
}
else if (document.layers)
{
this.obj = document.layers[name];
this.style = document.layers[name];
}
}




A little break from SOA and EA Frameworks :-)

Enterprise Architecture Definitions

As there are numerous definitions of SOA, there are also numerous definitions of Enterprise Architecture. Like with SOA, one may derive a definition of EA from reading between some of the definitions provided in many of the popular EA/SOA books


From these definitions, I get the idea that Enterprise Architecture is:

The current definition of an enterprise's business processes and the information technologies that aid in their execution. The Enterprise Architecture is a dynamic form of documentation which is subject to change in the short and long term due to changes in both business and technology. EA is a road map for the Enterprise concerning business process and technology to make IT a strategic asset.

Two of the main EA Frameworks I have looked at deal with it in different ways. The Zachman Framework seeks to classify the Enterprise by mapping Enterprise components into one of 36 classification squares. TOGAF presents an ADM(Architectural Development Cycle) which is an iterative cycle of how to define the Enterprise Architecture.


The definitions below are taken from my research in to SOA and Enterprise Architecture. I do not think it coincidence that so many of the SOA books mention Enterprise Architecture. They do complement one another. Maybe one could say that SOA is a style of architecture to help make Enterprise Architecture better. Or maybe Enterprise Architecture can tell the enterprise what to build with SOA. The two concepts are apparently strongly linked.

On Todd Biske's blog, he mentions a quote from David Linthicum on SOA and EA.

"Five years from now, we won’t be talking about SOA… It will all be folded back into EA." - David Linthicum


Enterprise Architecture Definitions:

“The enterprise architecture is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements for the company’s operating model. The enterprise architecture provides a long-term view of a company’s processes, systems, and technologies so that individual projects can build capabilities – not just fulfill immediate needs”1

“In simple terms, an Enterprise architecture identifies the main components of the organization and the ways in which these components work together in order to deliver the product and achieve the business objectives at the same time”.2


“You must recognize that the enterprise architecture is not static – it is constantly changing as business needs vary and technologies evolve. The task of the enterprise architecture group is to guide this evolution. To do so requires that the group keep one eye looking toward the future and the other focused on the realities of the present, while continually striving to draw the two together. Managing this evolution requires understanding the current state, articulating a vision for the future, and defining a roadmap for getting from here to there”3


“Enterprise Architecture is basically a discipline of IT architecture where we are concerned with IT in the context of the company as a whole – both IT and business”4

“An architecture description is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business.”5

“An enterprise architecture specification is to an organization what an urban plan is to a city. Therefore, the relationship between an urban plan and the blueprint of a building are comparable to that of enterprise and application architecture specifications.” 6


References:
1.Ross, Weill, Robertson,”Enterprise Architecture As Strategy”, 2006, p. 9
2.Grigoriu, “An Enterprise Architecture Development Framework”, 2006, p.22
3.Brown, “Succeeding with SOA”, 2007, p 115-116
4.Bloomberg,Schmelzer, “Service Orient or Be Doomed!”, p.121
5.The Open Group, TOGAF The Open Group Architecture Framework 2006 Edition
6.Thomas Erl,”Service-Oriented Architecture(Concepts, Technology, and Design)”, 2006, p. 87

My Definition of SOA and others

I have been reading on SOA for just over a year now and am feeling more comfortable with it. I know that SOA is not the same thing as web services although web services is probably the most commonly used technology, although SOA has been implemented in other technologies including CORBA.

My first crack at the definition of Service Oriented Architecture:

An SOA is an architecture consisting of reusable interoperable services to help make the enterprise more agile(reducing time to market) and efficient(increasing component reuse). Services should be discoverable, composable, provide an SLA and adequate security. An SOA is aided greatly by the use of an Enterprise Service Bus(ESB). The ESB acts as an intermediary between the service consumer and service provider. The ESB allows the service consumer and service provider to interact without knowing the location of the other, essentially avoiding any point to point integration problems.

I welcome other viewpoints on the definition of SOA, please comment if you have other ideas or agree more with one of the defintions listed below. Although, I think there is no true correct definition.

Antony Kimber has a posting on the definition of SOA as well at http://soaevolution.blogspot.com/2007/09/definitive-soa.html.

My eventual goal is to look at the benefits of Enterprise Architecture Frameworks in implementing an SOA. In particular, TOGAF and the Zachman Framework.


The following is a list of 9 SOA definitions from recent popular books on the subject or vendor websites:

“SOA is a form of technology architecture that adheres to the principles of service-orientation. When realized through the Web services technology platform, SOA establishes the potential to support and promote these principles throughout the business process and automation domains of an enterprise.” 1

“With an enterprise architecture grounded in Service Orientation, we’re looking for a broad set of rules and practices that govern the design and evolution of organizations that leverage business resources as Services. We call that set of rules and practices Service-Oriented Architecture”2

“SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. “Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.”3

“SOA is neither a technology nor a technology standard, but instead it represents a technology-independent, high-level concept that provides architectural blueprints, such as the ones outlined in the first part of this book. These architectural blueprints are focusing on the slicing, dicing, and composition of the enterprise application layer in a way that the components that are created and exposed as services in the SOA are not only technically independent but also have a direct relationship to business functionality”4

“SOA is supposed to provide clean, well-defined interfaces between business entitites – between service providers and service consumers”5

“Service-Oriented Architecture (SOA) is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.”6

“Service Oriented Architecture (SOA) is an architectural design pattern that concerns itself with defining loosely-coupled relationships between producers and consumers.
.. There is no widely agreed upon definition of SOA other than its literal translation. It is an architecture that relies on service-orientation as its fundamental design principle. In an SOA environment independent services can be accessed without knowledge of their underlying platform implementation. These concepts can be applied to business, software and other types of producer/consumer systems.
”7

“Service orientation is a means for integrating across diverse systems. Each IT resource, whether an application, system, or trading partner, can be accessed as a service.”8

“Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps users build composite applications, which are applications that draw upon functionality from multiple sources within and beyond the enterprise to support horizontal business processes.”9

References:

1. Thomas Erl,”Service-Oriented Architecture(Concepts, Technology, and Design)”, 2006, p. 55
2. Bloomberg, Schmelzer, “ Service Orient or Be Doomed”, 2006, p.126
3. Marks, Bell, “Service-Oriented Architecture – A Planning and Implementation Guide for Business and Technology”, 2006, p.1
4. Krafzig, Banke, Slama “Enterprise SOA – Service Oriented Architecture Best Practices”, 2005, p. 8
5. Brown, “Succeeding with SOA”, 2007, p xxii
6.https://www.opengroup.org/projects/soa/ ,Retrieved October 28, 2007
7.http://en.wikipedia.org/wiki/Service-oriented_architecture, retrieved October 28, 2007
8.http://www.microsoft.com/biztalk/solutions/soa/overview.mspx#EFBRetrieved October 28, 2007
9.http://www-306.ibm.com/software/solutions/soa/ Retrieved October 28, 2007

Enterprise Architecture As Strategy

Seeking further knowledge in Enterprise Architecture led me to read "Enterprise Architecture As Strategy" by Jeanne W. Ross, Peter Weill, and David C. Robertson. It seems that just as with SOA, EA lacks consistent definitions but this book provided some interesting business examples of how EA really can help your organizations.

They define enterprise architecture as "the organizing logic for core business processes and IT infrastructure reflecting the standardization and integration of a company's operating model". This boils down to 2 concepts: business process integration and business process standardization.

There are 4 types of operating models defined in regards to classifying companies:

1. Diversification (low standardization, low integration)
2. Coordination (low standardization, high integration)
3. Replication (high standardization, low integration)
4. Unification (high standardization, high integration)

The operating model represents a general vision of how a company will enable and execute strategies. Focusing on the operating model rather than on individual business strategies gives a company better guidance for developing IT and business process capabilities.


There are some real interesting case studies on how some successful companies like Seven Eleven Japan, CEMEX and UPS truly exploited their IT infrastructure to succeed in the marketplace. It is all about digitizing the core business processes.

Four stages of architecture maturity are defined:
1. Business Silos architecture - maximize individual business unit needs
2. Standardized Technology architecture - providing IT efficiencies through technology standardization and, in most cases, increased centralization of technology management
3. Optimized Core architecture - company wide data and process standardization to company model
4. Business Modularity architecture - manage and reuse loosely coupled IT-enabled business process components to preserve global standards while enabling local differences

Four strategic outcomes from enterprise architecture

1. Better operational excellence - low-cost, reliable and predictable operations
2. More customer intimacy - extraordinary customer service, responsiveness based on deep customer knowledge
3. Greater product leadership - first to market with innovative products and services
4. More strategic agility - respond rapidly to competitor initiatives and new market opportunities

They also mention to build the foundation one project at a time which must meet the short-term business goals and at the same time implementing or at least not undermining the company's architecture. (This was a point in Brown's "Succeeding with SOA") The goal is to have the enterprise architecture as a compass, directing the company toward its intended operating model. The IT Architecture should be viewed as an asset and not a cost.

Succeeding with SOA

I just finished reading Paul C. Brown's "Succeeding with SOA - Realizing Business Value Through Total Architecture". The book describes how to approach SOA from the business side focusing on value and organization rather than technology.

He outlines 4 keys to staying on track with the total architecture approach to SOA:
1. justify each project on its own business merits
2. have an explicit architecture step in every SOA project that precedes the actual development work
3. have an active SOA architecture group
4. have a living SOA project roadmap

I liked the idea that every SOA project must have it's own definite business merits as to continually supporting the SOA movement. The positioning of the Architecture group among the business silos in an effective way is discussed.

As far as SOA Project Leadership goes, there are 3 critical project leadership roles.

1. Project Manager - responsible for ensuring that the combined business process and systems changes actually generate the project's expected business benefits within the cost and schedule guidelines

2. Business Process Architect - determines the structure and organization of the overall business process

3. Systems Architect - determines the structure and organization of the information systems supporting the business processes


Brown really emphasizes the architecture of business processes along with system architecture. This really makes sense as SOA is about mapping services of the enterprise.

The Total Architecture Synthesis(TAS) is an approach to developing business processes and systems together. "When compared with the classic waterfall-style development, this approach significantly reduces project cost, time, and risk. When compared with agile programming, this approach validates architecture suitability before committing to implementation" This process leverages the use of standard UML(Unified Modeling Language) design notations to capture the design of both business processes and systems. The use of UML is a good idea, as I feel that having a well known tool for capturing information is desirable.

All in all, a common sense book and I look forward to the forthcoming book, "SOA in Practice". This accompanying book will be more aimed at SOA Architects, rather than the focus on Enterprise leadership of this book.

Enterprise Architecture and SOA

I am trying to scour for articles on Enterprise Architecture and SOA. Here is an article explaining how the relationship between EA & SOA.

The April 2007 edition on the IASA's Perspectives of the IASA "Special Issue: Enterprise Architecture - A 20 Year Retrospective"

"Enterprise Architecture and SOA: A Partnership" by Dr. Yan Zhao

There is also an interview with John Zachman, creator of the Zachman Framework.

The link to this article here

Please let me know of your opinions on EA framworks and their application to an SOA implementation. I am trying to focus more on the Zachman and TOGAF EA frameworks.