jump to navigation

Enterprise Architecture and Technology August 12, 2012

Posted by Sapna Sumanth in Enterprise Architecture.
add a comment

The only constant in business is change, but the velocity of that change is increasing. Business cycles continue to shrink, from years to months, placing enormous pressure on both business units and the Information Technology (IT) organization. Adding to this pressure is the fact that these two communities historically “speak different languages” and are infrequently synchronized in their intent or their methods [10] In the basic terms enterprise means an organization and enterprise architecture means the structure or the blue print of the organization. The structure describes the mission, values, the technologies, processes, people, information, underlying IT systems, applications and operations. Through Enterprise architecture, complex IT systems can be managed well by addressing to the current and the future needs and also helps in achieving a balance between the business and the IT sides of an organization. It’s highly important in delivering real business values. People play an important role in any organization. There must always exist collaboration, harmony & integrity. Selecting right people for different job roles is important. As Garter defines it ”The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment.”

Enterprise Service Oriented Architecture is an IT architecture that enables delivering information on demand. The primary structure of an SOA is a set of services as opposed to subsystems or components. The business drives these sets of services and exposes it to customers, partners and other portions of the organization. [1] SOA is essentially about bridging the gap between the business and the IT through well defined, business aligned services, developed by subscribing to established design principles, frameworks, patterns and methods. The objectives of EA and SOA are quite similar. However EA is a framework that covers all dimensions of IT architecture for the enterprise, while SOA provides an architectural strategy that uses the concept of service as the underlying business-IT alignment entity. The key concepts of SOA include – Service provider, Service registry and Service consumer [2]

Service provider: Provides services based on a pre-defined service contract that guarantees a minimum service level, which may include performance, reliability and usage cost.

Service Consumer: Consumes a service or an assembly of services to deliver a particular business process.

Service Registry: Holds the descriptions and contracts associated with the services available for consumption.

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together [3] SOA enables the creation of an adaptable EA that uses a set of different types of platforms and implements capabilities as reconfigurable loosely coupled services. The ideas behind service oriented architecture are not new – attempts for distributed computing gave been made before. The object Management group’s Common Object Request Broker architecture (CORBA) defined specifications that enabled vendor independent architecture and infrastructure for applications to work together over networks (OMG 2008) [4]

Today, CORBA is extremely feature-rich, supporting numerous programming languages, operating systems, and a diverse range of capabilities—such as transactions, security, Naming and Trading services, messaging and publish-subscribe services—that are essential for many enterprise-level applications. Many newer middleware technologies claim to be superior to CORBA but actually have to do a lot of “catching up” just to match some of the capabilities that CORBA has had for a long time. With such an impressive list of benefits, it is little wonder that CORBA is being used successfully in many industries, including aerospace, consulting, education, e-commerce, finance, government, health-care, human resources, insurance, ISVs, manufacturing, military, petrochemical, publishing, real estate, research, retail, telecommunications, and utilities. CORBA is used in everything from billing systems and multi-media news delivery to airport runway illumination, aircraft radio control and the Hubble space telescope. Most of the world’s telephone systems, as well as the truly mission-critical systems operated by the worlds biggest banks, are built on CORBA [5]

An enterprise service bus (ESB) is a software architecture model used for designing and implementing the interaction and communication between mutually interacting software applications in Service Oriented Architecture. As a software architecture model for distributed computing it is a specialty variant of the more general client server software architecture model and promotes strictly asynchronous message oriented design for communication and interaction between applications. Its primary use is in Enterprise Application Integration of heterogeneous and complex landscapes [7]

ESB provides the key higher level services that are required in order to effectively implement Service-Oriented Architecture (SOA) including management and monitoring, security, service orchestration, support for both asynchronous messaging and request-reply, and adapters for a variety of packaged applications and technology platforms. The ESB should be used whenever feasible to mediate communications between service providers and service consumers. The ESB selected at NIH is TIBCO BusinessWorks. The ESB provides a number of higher-level services that facilitate service reuse and event-driven architecture:

  • Both message-based and request-reply communications
  • Rule-based routing of messages
  • Security
  • Management and monitoring
  • Process orchestration
  • Message transformation

The ESB provides adapters for a variety of technology platforms including J2EE, .NET, and relational databases. These are described in detail in the Integration Adapters brick [6]

Data architecture in Information Technology is composed of models, policies, rules or standards that govern which data is collected, and how it is stored, arranged, integrated, and put to use in data systems and in organizations. A Data Architecture is often the design of data for use in defining the target state and the subsequent planning needed to achieve the target state. It is usually one of several architecture domains that form the pillars of an enterprise architecture or solution architecture [9] An EDA enables organizational change because it organizes data around the enterprise’s data subjects. Such organization permits multiple application systems to use the shared data resource. An EDA pulls together, validates, cleanses and integrates data from disparate source application systems, providing the end-user community with an integrated view of enterprise data. As a result, operational departments can access the data for strategic and tactical decision support, day-to-day operations and general reporting. With enterprise data modeling, it creates a robust enterprise data model and populates the enterprise-level databases, the DBMS (database management system) software provides the capabilities necessary to share data across the enterprise. The DBMS not only ensures that there will be data integrity, security, concurrency and high enterprise-level database availability, but it also provides fault-tolerant backup and recovery, performance monitoring and system management capabilities [8]

Web Services are becoming the form most used for implementing an SOA. A Web Service is a software system designed to support interoperable machine-to machine interaction over a network. It has an interface described in a machine-process-able format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards [12].  Web services that perform useful task would often exhibit the following properties:

1. Discoverable: One of the critical requirements for a web-service is to provide service to other users. So it has to be discovered and accessed by consumers (human users or other Web services).

2. Communicable: This is often asynchronous messaging as opposed to synchronous messaging.

3. Conversational: A conversation involves sending and receiving documents in a context. This involves complex interactions between Web services and entails multiple steps of communication that are related to each other.

4. Secure and Manageable: Security, manageability, availability, and fault  tolerance are critical for a commercial web-service.

Organizations face an increasing challenge to integrate existing technology investments with evolving applications architectures. The introduction of web services as a solution to a diverse platform environment, the use of XML as an integration tool among disparate applications, and the expansion of EAI tool-sets to help form new integration layers all are topics of deeper consideration for an organization seeking to build a flexible and scalable Enterprise Architecture [10]


[1] http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/index.html

[2] http://www.infosys.com/consulting/soa-services/white-papers/Documents/SOA-link-EA-SOLA.pdf

[3] http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

[4] http://dspace.cc.tut.fi/dpub/bitstream/handle/123456789/151/perko.pdf?sequence=1

[5] http://www.ciaranmchale.com/corba-explained-simply/benefits-of-corba.html

[6] https://enterprisearchitecture.nih.gov/Pages/EnterpriseServiceBusPattern.aspx

[7] http://en.wikipedia.org/wiki/Enterprise_service_bus

[8] http://www.information-management.com/issues/20040101/7910-1.html

[9] http://en.wikipedia.org/wiki/Data_architecture

[10] http://www.liquidhub.com/docs/Horizons-EntArch.pdf


How does technology support Enterprise Architecture? August 12, 2012

Posted by daleklein in Enterprise Architecture.
add a comment

The Gartner definition of enterprise architecture is: “Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment.”  Now that we have a common understanding of enterprise architecture, we can take a look at how technology supports Enterprise Architecture. [1]

Through the creation, communication and improvement of principles and models that represent an enterprise’s desired future state, one can enable an enterprise’s evolution.  The tool that helps one move toward that desired future state is the use of different technologies.  The idea is to improve corporate agility, accelerate the time-to-market of new products and services and improve operational efficiency by reducing the total cost of ownership.  We want to take a look at these technologies as they apply to the ideas of a business organization, business and information integration, and EA maturity.  Some of those technologies are as follows:

  1. A common database (including data warehousing)
  2. OMG and CORBA
  3. Web-services
  4. Service Oriented Architecture
  5. Enterprise Service Bus

For most companies today, data integration has transformed itself from a luxury state into a necessity.  How well a company integrates its data can be the difference between sales success or failure, customer retention or customer loss.  Today we live in a world where customers have instant access to a wealth of information and who have a pre-existing expectation about their interactions.  Databases are an important part of the database architecture in enterprise architecture.  Data can be held in legacy or package systems where you might not even have the details of the data structure.  Sometimes the data resides in multiple systems that are not interconnected or even with external systems that are service providers.  The data can vary in quality, format and even meaning.  A business organization’s objective is to have improved data collection and to make more effective use of the data. [2] [3] An operating model provides us with an abstract representation of a business entity and how it operates across processes and technology domains across the entire organization.  It is typically used to create a framework which helps formulate a strategy or a strategic scheme which will support integration while providing value to the business organization.  It is the primary driver of the level of standardization and data sharing which in this case we are looking at how to plug databases into that framework.  The technology will start out in silos; move to a standardized technology and eventually to an optimized core as it moves through the maturity model. [4]

The next technology involves the Object Management Group (OMG) and Common Object Request Broker Architecture (CORBA).  CORBA is a standard that is defined by OMG.  CORBA is a middleware that allows software components that exist on different systems written in different languages to all work together.  It allows them to act like a single application or set of services.  As a technology it allows you to normalize the interfaces between new and legacy systems.  CORBA can provide flexible data typing and enforces a tightly coupled data typing in order to reduce human error.  It acts as a bridge stretching between software components.  The problem of recent years is that companies have increased their use of the Internet and Web which further increases the pressure and complexity for IT teams to integrate the systems.  The challenge is to link databases and applications together in a way that provides the Web users with an almost instantaneous response.

Next we move on to web services.  Web services are a method of communicating between two electronic devices over a network or more specifically through the internet.  Web services are pervasive, simple, and most importantly platform-neutral.  By using a technology such as a Web service it allows you the ability to rapidly create enterprise applications that are open and interoperable, can be easily enhanced and updated.  Today technologies and business needs are in a constant state of flux.  The point of enterprise architecture is to help you manage the dynamic changes and modified organizational objectives in order to arrive at some future state which itself can be evolving.  The challenges faced by IT teams is that the same business service might be presented as a Web service, as a Web page, perhaps an application screen or a message to a wireless device.  The integration practice provides a structured information and delivery framework.  The purpose is to help break down the “silos” that are inherent in many legacy systems within an enterprise.  In the context of enterprise architecture, Web services are designed to deliver measurable results along with an accelerated return on investment.  They are a means of helping EA strike the right balance between the business and IT needs. [5]

“A Service-Oriented Architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components. “ [6]  If you read various articles and blogs on the subject of SOA they point out the blurring of SOA and web services as perceived by many individuals. The terms are often used interchangeably. We turn to Wikipedia for a definition to understand the difference: “Web services can implement a service-oriented architecture. Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages. These services can represent either new applications or just wrappers around existing legacy systems to make them network-enabled. “ [6]

“At the enterprise architecture level, it is always about the business. This is not a bad thing, on the contrary, the enterprise architecture perspective should be focused on the business needs in order to make sure IT serves the business and not vice versa.  SOA characteristics can allow you to take an incremental way for removing legacy systems by exposing existing functionality using new SOA interfaces before you actually replace the underlying system.” [7]  SOA is another means of aligning business and IT while at the same time making them both more agile.  Services become the foundation for more easily creating new strategic solutions.  So, why do we need to be more agile?  The answer is that more and more businesses have to deal with a global economy and business requirements change at an even faster rate than just a few years ago.  By implementing an SOA using Web services you are more likely to have a competitive advantage over your competitors that do not use them.

Our last technology is an enterprise service bus (ESB) which is software architecture for middleware that provides fundamental services for the more complex architectures.  Typically it will incorporate the features needed to implement SOA.  ESB can be thought of as a mechanism for accessing applications and services to present a single, simple interface to end-users through the Web.  What ESB basically does is to hide complexity, simplify access, allow developers to use generic forms to handle the complex details that are going on in the background.  A large art of the appeal of an enterprise service bus is its ability to support incremental service and application integration as determined by the business requirements. [8]

Some of the primary duties of enterprise service bus are to monitor and control the routing of a message exchange between services.  It is also responsible for resolving issues between communicating service components, control deployment and versioning of the services involved.  It can also marshal redundant services when present.  ESB assumes that the services are autonomous and whose availability cannot be guaranteed.  It deals with this assumption by routing the message through a bus to be buffered.  This allows it to inspect and enhance the content and then filter, correct and reroute the message flow. [8]

Enterprise service bus is important to SOA implementation, its effects on costs, development and the deployment process.  I think it is important to understand that the functions and structure of its design permit rapid change, easy connections and control of services and processes in a SOA-based application.

I think that in looking at these five different technologies you should have noticed that each successive technology discussed appears to be an enhancement from the previous technology.  Any of these technologies can be implemented into a business organization.  Just as each technology is an advance forward from the previous it also representative to the steps that an organization goes through as they progress through the four stages found in the enterprise architecture maturity model.

Works Cited:

[1] Lapkin, Allega, Burke, Burton, Bittler, Handler, “Gartner Clarifies the Definition of the Term ‘Enterprise Architecture’,” Gartner, Inc., 2008.

[2] “The State of Customer Data Integration 2012, the What, Why and How of CRM Integration,” Scribe, 2012.

[3]A. J. a. R. Wiggins, “Modeling the Enterprise Data Architecture,” 2003. [Online]. Available: http://www.andrewj.com/publications/Modelling the Enterprise Data Architecture.pdf. [Accessed 8 August 2012].

[4] T. Kaczmarek, “Enterprise Architecture Maturity Model,” 2012.


Available: http://www.lucidtechinc.com/enterpriseintegration.html. [Accessed 8 August 2012].

[6] “Wikipedia,” [Online]. Available: http://en.wikipedia.org/wiki/Service-oriented_architecture.%5BAccessed 24 July 2012].

[7] A. Rotem-Gal-Oz, “What is SOA anyway? Getting from hype to reality.”.

[8] M. Rouse, “enterprise service bus (ESB),” [Online]. Available: http://searchsoa.techtarget.com/definition/enterprise-service-bus. [Accessed 9 2012]

A more modular EA August 12, 2012

Posted by Jiaqi Wu in Enterprise Architecture.
add a comment

Technology has become an integral part of every business. Its benefits are significant to any business. However its benefits also vary by the degree by which it is implemented to work for the business. Designing the IT and other technology infrastructure for a business is known as Enterprise Architecture (EA). An effective EA implies technology that is aligned with business goals and processes.

Service oriented architecture (SOA) is the modern approach to business IT organization. As software projects become larger, a more strict and organized approach is required in order to maintain software. SOA and web services are different methods of providing a platform on which applications can be developed. In both these methods, services are loosely coupled components of which are individually maintained. Combining multiple services together, applications can be developed in order to utilize common functionality while reducing repeated code.

The benefits of SOA to a business are vast. In terms of business organization, software components are bundled into services. SOA operates on the principle of loosely coupled services. Since services are loosely coupled, they can operate in any compatible SOA environment. This allows businesses to share services and also allows services to be traded. By using modular services, much less software code needs to be repeated thereby reducing the overall amount of necessary code to write.

One implementation of SOA is web services. In SOA, services must have a form of communication in order to be utilized by an application. In web services, this communication between services is through standard internet protocols used for the web. Because of this form of communication, data is usually transferred as HTML, XML or other plain text languages. This is advantageous in that the communication protocol is widely compatible as the web has largely adopted this form of communication. However plaintext communication occupies much more overhead in data transfer compared to services which communicate using other frameworks in a more enclosed network environment.

The Object Management Group (OMG) is a consortium which defines standards for software modeling. One of its standards is the Common Object Request Broker Architecture (CORBA). It allows any CORBA application on any type of computer, operating system, and programming language to interact with other CORBA applications [1]. There are numerous benefits to this from an EA perspective. Mainly, it is a matter of allowing software integration. The more integrated a company’s IT can be, the better streamlined its workflow. In addition, CORBA can be used to enable service oriented architecture by allowing communication across a wide variety of software applications in a flexible manner. SOA requires a communication protocol in order to allow services to communicate and utilize features. Since services are also considered independent and loosely coupled, a good advantage that CORBA enables is that services can be written in different platforms using different programming languages.

Another technology that can be used to mediate communication between services in an SOA is the enterprise service bus (ESB). ESB is a software design model used to mediate the interaction between software applications [3]. Operating through many layers of software, the overview of this technology is to allow applications on different platforms to communicate. This is similar to what CORBA enables. This technology is beneficial in that it is highly scalable and flexible. Many ESB suites are now utilizing OSGi which allows for dynamic loading and unloading of components [2]. This enables the ESB suite to be patched with zero downtime [3]. A downside of ESB suites is that they also contain a lot of overhead [2].

Data warehousing is a method by which all data in an organization is stored in what is perceived as a central repository. All of the operational departments in the organization access their data through a single database interface. This interface then organizes the data into data marts [5][6]. All of these operations occur behind the scenes of the data warehouse implementation. The benefit of this is that it can easily be incorporated in SOA. By creating a single Data warehousing service, all operational applications can be developed using this single data warehouse service to access data.

As EA becomes more sophisticated, we slowly discover that SOA is a modular and organized approach to implementing it. An increasing number of frameworks are being developed which center around allowing diverse components to interact with each other. By allowing this communication, software components are much easier to maintain and systems are much more scalable.


[1]    CORBA Basics. Object Management Group. Internet http://www.omg.org/gettingstarted/corbafaq.htm/ Accessed on 10 August 2012.

[2]    Hype Cycle for Application Infrastructure 2012. Gartner Reports. Internet http://my.gartner.com/portal/server.pt?open=512&objID=260&mode=2&PageID=3460702&resId=2091716&ref=QuickSearch&sthkw=enterprise+service+bus Accessed on 10 August 2012.

[3]    Enterprise service bus. Wikipedia, the free encyclopedia. Internet http://en.wikipedia.org/wiki/Enterprise_service_bus Accessed on 10 August 2012.

[4]    Beyer, Mark. Information Management in the 21st Century. Gartner Reports. Internet http://my.gartner.com/portal/server.pt?open=512&objID=260&mode=2&PageID=3460702&docCode=215806&ref=docDisplay Accessed on 10 August 2012.

[5]    Data warehouse. Wikipedia, the free encyclopedia. Internet http://en.wikipedia.org/wiki/Data_warehousing Accessed on 10 August 2012.

[6]    Beyer, Mark. Edjlali, Roxane. Understanding the Logical Data Warehouse: The Emerging Practice. Gartner Reports. Internet http://my.gartner.com/portal/server.pt?open=512&objID=260&mode=2&PageID=3460702&resId=2057915&ref=QuickSearch&sthkw=data+warehouse Accessed on 10 August 2012.

Enterprise Architecture August 10, 2012

Posted by mattpassini in Enterprise Architecture.
add a comment

Key Technologies in Enterprise Architecture

One of the most widely accepted statements of what defines enterprise architecture is as follows: “Enterprise architecture is the process of translating business vision and strategy into effective enterprise change” [1].  It is important to understand that the goal of EA is not to simply create an end product, but to continually set the strategic goals that drive the business forward.  The separate organizational units must take these goals, utilize the architecture that EA has set forth, and align themselves with the other organizational units to create one unified and aligned business that is agile, effective, and efficient.  However, the business units can be perfectly aligned and the enterprise architecture can have solid building blocks, but without a streamlined, efficient, and powerful technology backed foundation, enterprise architecture is doomed to failure.  Two of the biggest aspects of the technology backing an enterprise architecture are integration and interoperability – two seemingly contradicting values.  The following are five technologies and standards are essential in creating technology that is not only streamlined and integrated, but also highly available from disparate, heterogeneous systems.

Perhaps the most integral part of integrated business is a common database, or a data warehouse.  A data warehouse is a singular data store which combines data from varying internal systems as well as external environments and cohesively stores the data in a centralized manner.  Once collected, the data can be transformed to create consistency, analyzed, and finally reported in the form of useful information.  While some may find it hard to determine downsides to this apparently obvious technology, there are indeed business models that do not benefit as highly from such a system.  For instance, a diversified business model would likely only benefit from combined HR and a few other central, non-diverse business units.  Aside from those, a diversified business model would require very unique data stores for each of their diversified lines of business.  Another downside of a data warehouse is that “the warehouse is useful only as a reference – it does not offer real-time data across applications.”[2] This issue is corrected at the heart of the following technologies and standards.

When dealing with anything, following industry standards – or actively defining new ones when necessary, plays a crucial role in how solid your technology foundation will be.  The Object Management Group (OMG) is an organization that aims to “quickly develop a specification in the hopes that it will become a de facto standard.”[3] The Common Object Request Broker Architecture (CORBA) is one such standard brought forth by OMG.  CORBA sets a blueprint for solving the real-time data sharing problem by defining standards that enable software written in varying computer languages and running on differing computers and systems to interoperate and work together.

Service Oriented Architecture is one such take on an implementation of that ideal.   SOA defines an architecture which “requires loose coupling of services with operating systems and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications.”  Much like a central data store, or data warehouse, a SOA provides a centralized location for communicated at the application level.  This interoperability provides instant access to any system capable of communicating via varying SOA implementations, such as web services, which will be discussed below.  The level of abstraction, loose coupling, discoverability, integration, and reusability vitally enhance an enterprise architecture’s application domain.  Much like the downside to data warehousing, SOA may provide limited benefits to a diversification business model due to the varying diverse lines of business requiring their own set of software and applications, limiting the number of centralized SOA opportunities.

One concrete implementation of SOA is the utilization of web services.  A web service is “a software system designed to support interoperable machine-to-machine interaction over a network.”[5] Disparate systems generally use a Web Services Description Language (WSDL) in order to communicate and interact with the web service.  Typically, SOAP messages are sent via HTTP serialized in XML. This implementation allows for varying access points and devices to consume the capability of an application.  The definition is completely abstracted from the coding implementation, so end user’s consuming the information need not worry about the back end.

Abstracting the entire SOA and web services process even further, an Enterprise Service Bus (ESB) can be implemented as a backbone to the SOA.  ESB is an architecture which is used to model the interoperability and communication between two interacting endpoints in a SOA.  Much like a hardware bus in a computer handles the transfer of data between system components; an ESB allows applications to be easily turned on and off of the network without needing to take down the actual endpoints.  The ability to hot-swap configurations allows for easier and faster changes and even looser coupling.

One of the major goals of EA is to increase agility and decrease the time required to make changes.  Once data is integrated into a singular data store, and systems are integrated and highly interoperable, the organization becomes streamlined and is able to adapt to the market quickly and efficiently.  Data warehousing provides essential and consistent information from the data given, but lacks the real-time monitoring that is necessary in an integrated organization.  A Service Oriented Architecture, backed by an Enterprise Service Bus, and implemented using Web Services is an excellent example of a truly robust set of technologies working in harmony to create an efficient business with a solid foundation for the maturing Enterprise Architecture.

[1] Gartner Clarifies the Definition of the Term ‘Enterprise Architecture’
Published: 12 August 2008 ID:G00156559

[2] Ross, Jeanne W., Peter Weill, and David C. Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, MA: Harvard Business School, 2008. pp. 7

[3] Soley, Richard. What Makes a Standard?. http://blog.omg.org/ 04/18/2012

[4] Bell, Michael Introduction to Service-Oriented Modeling. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. 2008. pp. 3

[5] W3C. February 11, 2004. Retrieved 2012-08-09.

Enterprise Architecture and Technology August 10, 2012

Posted by janettheresjohn in Enterprise Architecture.
add a comment


Based on the characteristics of a business, enterprise architecture can fall into one of the four operating models:

  1. Coordination – coordination model uses high business process integration and low business process standardization. This operating model involves the coordination of stakeholders to develop an enterprise architecture that has some common appearance. Coordination requires good communication between stakeholders.
  2. Unification – Unification model uses high business process integration and high business process standardization. All stakeholders work together to create unified enterprise architecture.  This operating model includes coordination, integration and common processes across the entire organization. This operating model require strong core of process and systems.
  3. Diversification – Diversification model uses low business process integration and low business process standardization. Stakeholders for each of the sub business drive the implementation of the enterprise architecture. This operating model provides diversified business appearance. Every sub businesses use some shared elements of infrastructure.
  4. Replication – Replication model uses low business process integration and high business process standardization. This model uses more standards and as a result the architecture can be replicated and customized for each sub business.  The outcome will be multiple versions of a common core. Each replica will be very consistent.

In this blog post, we will be looking into how technology supports EA. We will look into the strengths and weaknesses of these technologies with respect to the four operational models, integration and maturity.

Service Oriented Architecture

IBM SOA Center of Excellence’s provide the following definition for Service Oriented Architecture (SOA). “A Service-Oriented Architecture is an enterprise-scale IT architecture for linking resources on demand. These resources are represented as business-aligned services which can participate and be composed in a value-net, enterprise, or line of business to fulfill business needs. The primary structuring element for SOA applications is a service as opposed to subsystems, systems, or components.” [1] SOA is more than just the architecture. Similar to an Enterprise Architecture, SOA needs governance as well as a transition roadmap that allows enterprises to fully adopt it. [1] From business perspective, Service Oriented Architecture involves a set of services that a business wants to expose to its customers and partners or other portions of the organization. From an architecture perspective, it is an architectural style which requires a service provider, requester, and a service description. From implementation perspective, SOA is a programming model complete with standards, tools, and technologies, such as Web services.  [1]

Service Oriented Architecture touches the four operating models of an Enterprise Architecture; coordination, unification, diversification and replication. SOA touches the coordination operating model by demonstrating business process integration and standardization. For the efficient use of a SOA, the architecture must demonstrate good business process integration and apply business process standardization. Interoperability among different systems and programming languages provides the basis for integration between applications. [2] Service oriented architecture integrates widely disparate applications for a Web-based environment and uses multiple implementation platforms. Service oriented architecture defines the interface in terms of protocols and functionality, which require coordination between business units.

SOA demonstrate the unification operating model by applying standards, tools and integration techniques. Services and their consumers communicate with each other by passing data in a well-defined, and shared format, or by coordinating an activity between two or more services. [2] Each service implement one action and it will not use other services. Therefore, SOA support diversification operating model. Services are defined by the different business functionalities (coordination) and they can be reused for different purposes (replication).  Users can combine and reuse services (unification).[2] SOA uses high level of business process integration. As the system matures, to create a new application from existing services, one requires only orchestration of the existing services and the marginal cost of creating a new application is very low.  [2]

Enterprise Service Bus

The Enterprise Service Bus (ESB) is a key component for delivering a service-oriented infrastructure for IT agility and alignment with business needs. The Enterprise Service Bus should have seamless integration with the service registry and service management components to accelerate configuration and deployment management and management of shared services across the enterprise. The service bus should be able to receive any synchronous or asynchronous message in any protocol and route it to the destination based on configuration rules. In addition, ESB should provide the capability to transform the message to the format required by the destination. [3]

The service bus supports the diversification operating model as it support message brokering between heterogeneous environments. ESB supports multiple message formats including SOAP, SOAP with attachments, XML, structured non-XML data, raw data, text, and e-mail with attachment. [3] ESB supports the unification operating model as it supports multiple standards and protocols to transport messages between service end points. ESB support protocols such as file, FTP, HTTP(s), multiple JMS providers, RMI, web services, CORBA, DCOM, and e-mail (POP, SMTP, IMAP), and SIP.  It supports the latest security standards and multiple authentication models. ESB support configuration driven routing as it route messages based on some policies. ESB support the replication operating model and provide high availability. It can deploy new versions of services dynamically through configuration.

A service registry acts as a catalog of services available to architects, developers, operations and business managers. [3] The service producer publishes the service to the service registry which is leveraged by the service consumers. It also acts as the system of record for the business policies that it enforces at runtime. The service registry also supports the four operating models of EA. The registry provides replication, service mapping, configuration management, and it is platform independent. [3]

Web Services

The W3C definition for web service is that it is a software system designed to support interoperable machine-to-machine interaction over a network. In general, web service is a method of communication between two electronic devices over the internet.  [4] Using Web services, applications can publish its function or message to the rest of the world. Web service has an interface described in a format called Web Services Description Language (WSDL). The basic web service platform is XML and HTTP. Web services use XML to code and to decode data, and SOAP to transport it. Other systems interact with the Web service using SOAP messages.

In the previous section we have looked into service oriented architecture. Web services can implement a service-oriented architecture. Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages. [2] Web services can play the role of either the service provider or the service consumer or both. The service provider creates a web service and publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or whether to exploit them for other value. The web service client (service consumer) locates entries in the service registry and then binds to the service provider in order to invoke one of its web services. Whichever service the service consumer’s needs, they have to search in the service registry and bind with the required service and use it. [2]

A common database

Service Oriented Architecture creates a federation of resources. It establishes and maintains data flow to a federated database system. This allows new functionality developed to reference a common business format for each data element. [2]


Wikipedia definition for the Common Object Request Broker Architecture (CORBA) is that it is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers  to work with each other like a single application or set of services . [5] CORBA uses an interface definition language (IDL) to specify the interfaces which objects present to the outer world. CORBA specifies a mapping from IDL to a specific implementation language.

Service Oriented Architecture and CORBA have many similarities. Both SOA and CORBA are ways to interoperate with application.  CORBA services, such as transaction, security, and directory, are similar infrastructure services required of Web services in an SOA. [6] However, the key differences between SOA and CORBA, makes SOA more successful than CORBA. CORBA is a broker-based architecture that was challenged to take the industry to the next level. On the other hand, a SOA is flexible and amenable to change. An SOA addresses business-process interoperability between partners and customers over the Internet with compensated transactions, not only short-lived transactions.  For business programming, CORBA is best suited for tightly coupled transactional systems requiring high security. [6] CORBA and SOA based on Web services have different objectives. CORBA focuses on objects to create a distributed computing environment and Web-service-based SOA focuses on business-process interoperability and documents. [6]


Now a days, a large number of third-party software companies offer software services for a fee.  SOA systems mayconsist of such third-party services combined with others created in-house. This has the potential to spread costs over many customers and customer uses, and promotes standardization both in and across industries. [2] As enterprises move more and more into cloud computing platform, the Service Oriented Architecture might help them with an easy transition to cloud. However, enterprises should be careful with adopting SOA while developing EA. According to IBM developer works white paper, an enterprise that’s adopting SOA while developing EA and its governances may encounter problems if the similarities and overlaps between EA and SOA are not recognized and accounted for. [1] Interoperability among different systems and programming languages is a big strength of service oriented architecture and it also support the four EA operations models.


  1. Ibrahim, Mamdouh, Service-Oriented Architecture and Enterprise Architecture, IBM developer works, Published on 26 April 2007,  http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/, Retrieved on 8 August 2012
  2. Service-oriented architecture, http://en.wikipedia.org/wiki/Service-oriented_architecture, Retrieved on 24 July 2012
  3. Durvasula, S. et al., SOA Practitioners’ Guide Part 2: SOA Reference Architecture, 15 September 2006, http://www.soablueprint.com/whitepapers/SOAPGPart2.pdf , Retrieved on 8 August 2012
  4. Web service, http://en.wikipedia.org/wiki/Web_service , Retrieved on 24 July 2012
  5. Common Object Request Broker Architecture, http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture, Retrieved on 8 August 2012
  6. West, Kenneth, SOA vs. Corba: Not Your Father’s Architecture, Published on 06 July 2004, http://www.wallstreetandtech.com/articles/22103721, Retrieved on 9 August 2012

August 10, 2012

Posted by 8952chavezr in Enterprise Architecture.
add a comment

Any tool can be useful in EA.  They key is to properly design how it will be used.  The difference between tools is the amount of effort it takes to make them useful.  Some tools and processes are designed to be very maintainable.  Others only think they are.  It is important for the EA team to first understand the needs of the business and then leverage the experience and legacy systems as much as possible.  Just because a technology is the latest and greatest does not mean it will be the easiest to use.  Certainly, many new technologies like web services and SOA are designed to make an organization agile and loosely coupled.  However, there may be other tools that will allow the team to leverage systems already in place much faster than building everything from scratch.  Here, we present some of those tools and describe what makes them useful and where they fall apart.

Common Database (Data Warehousing)

For storing data, databases have been the go-to standard for a long time.  There is no escaping them.  They are exceptional for storing data and retrieving that data.  However, care must be taken when using databases in an Enterprise Architecture.  Relational databases “are a disaster for querying because they cannot be understood by users and they cannot be navigated usefully by DBMS software” [10].  In order for database to be useful, they need to be designed just as any other part of the EA is designed, with an understanding of the business vision and a clear definition of the desired future state.  Instead of a relation model even one that is normalized in the Third Nominal Form or higher, some suggest using a multidimensional model [6].  “In Data Warehousing, data is often organized according to the multidimensional paradigm, which allows data access in a way that comes more natural to human analysts. The data is located in n-dimensional pace, with the dimensions representing the different ways the data can be viewed and sorted (e.g. according to time, store, customer, product, etc.)” [1].  Because the models are easier to understand, they are easier to communicate, which is a large part of making EA successful.

Some of the sticking points with data warehouses are the maintainability and the integration effort.  If we use a dimensional model, it can be difficult to modify the structure later on if the business decides it needs a change, either because the business itself changed or something was missed.  It can also be complicated to load data from the different systems because the unified dimensional model may not make sense to the operational systems.  In terms of the relational model, the major downside is understanding the data and writing the queries to join the tables to create the models that make sense from the EA perspective [7].  For a mature EA, a shared database would require an extra layer on top, possibly a web service, to retrieve the data within it.  Because a mature EA is agile and loosely coupled, the layer or web service on top of the EA would allow the database to change and the model to remain the same.  They key is to identify which model type can be best leveraged by the EA team and how to translate it to the model communicated to the rest of the team.


When we say that any tool can be leveraged to support a well-designed EA, CORBA is a key example.  CORBA has long been dismissed as a failed standard and technology.  While “CORBA enables separate pieces of software written in different languages and running on different computers to work with each other like a single application or set of services,” the implementation has proven troublesome [11].  The concept is sound and is exactly what is needed to implement a loosely couple EA, CORBA is just too weak to be a standard and instead leads to proprietary implementations where actual integration is too difficult and too complex [2]. The key to CORBA is defining interfaces which can be implemented in multiple languages and shared in memory at runtime, accessed either locally or remotely [11].  It sounds straightforward, but over time, “many of the APIs were complex, inconsistent, and downright arcane, forcing the developer to take care of a lot of detail” [3].

CORBA is essentially a dead technology. “Today, CORBA is used mostly to wire together components that run inside companies’ networks, where communication is protected from the outside world by a firewall” [3].  However, it does not mean it is useless.  With the right amount of design and governance, it can still be leverage to integrate business EA in a mature organization.  The amount of effort is on the higher side compared to some other technologies, but if done with care, EA teams can create reusable components using CORBA.  The one downside is the amount of effort might reduce the agility of the organization, but only if the CORBA based components have to change frequently.


Before we go too far in describing Service Oriented Architecture, “we have to clearly distinguish between SOA and Web Service specifications – sometimes, both are mixed up: SOA is an architecture, Web Service specifications define an interoperable platform supporting a SOA” [4].  Therefore, SOA is not a technology per say.  It is a description of how an EA should be designed.  It is “a set of principles and methodologies for designing and developing software in the form of interoperable services” [5].  It means that when components are developed they are developed with a very well defined interface and data set which is accessible regardless of the programming language or technology stack of the consumer.  This is extremely important to developing a mature EA that is loosely coupled and agile.  Each service that is developed should somehow map to part of a process of how data is defined and moved within the organization.  The reusable components can then be combined in new ways to improve the processes.  Still, if not done correctly, there can be a lot of churn in developing the interfaces.  If the interface changes in one component, there needs to be an effective way to communicate that change to all the teams leveraging the service.

Web Services

While SOA is more of an approach to EA, web services are actual technologies that can be used to achieve a SOA.  Discrete endpoints live on the network with well-defined inputs and outputs.  It is rather similar to CORBA, but the interfaces (HTTP, XML, JSON) are much more standards than CORBA is.  By leveraging well-known and mature standards like HTTP and XML, web services make it easy to focus on the business logic of the data model and the process.  This lets the EA team focus on understanding their organization and how best to implement the services to support the processes.  One of the important advantages of web services comes from the fact that they use well-known standards.  These standards make it simple to deploy “automated interactions between distributed and heterogeneous applications and for connecting business processes, which might span companies’ boundaries” [5].  Based on this concept, another concept known as mashup has emerged.  The goal is to create new applications by taking existing resources on the Web and using the data and APIs made public by those resources [8].  This allows a business to transform by finding new and better ways of doing things, ways it may not have identified without the web services.  The downside is that security is very important if these services will be available on the World Wide Web.  To make them truly useful, they should be made open to allow collaboration even outside the business.  Still, this will be a decision for the EA team based on the goals of the business.

Enterprise Service Bus

The service bus is a centralized component that directs traffic within the organization. It understands the request and directs it, transforming the request and response as necessary [9]. This service bus means that we can achieve reusability of systems that may already be in place or new ones that are developed without making changes everywhere. Consumers do not need to change their interface as long as the central service bus understands the request and transform it as necessary.  Like web services, the service bus is a tool designed to be used in an SOA.  The service bus can be very useful in leveraging legacy systems because it can delegate messages (requests and responses) to the appropriate system, transforming the data as necessary.  However, care must be taken in understanding how the integration takes place.  When possible, a standard for the data must be established.  It would be easy enough to transform the data for each and every consumer, but it will make it easier to define a standard for development moving forward.  This will make the EA team more agile.


[1]Stefanov, V. “Business Metadata for the DataWarehouse”, Enterprise Distributed Object Computing Conference Workships. IEEE. October 2006

[2] Chappell, D. “The Trouble with COBRA”, David Chappell & Associates, May 1998 http://www.davidchappell.com/articles/article_Trouble_CORBA.html

[3] Henning, M. “The Rise and Fall of COBRA”, ACM Queue, June 1, 2006. http://queue.acm.org/detail.cfm?id=1142044

[4] Tilkov, S. “Web Services Guru Dr. Frank Leyman on SOA”, InfoQ, Aug 14, 2006, http://www.infoq.com/articles/Leymann-about-SOA;jsessionid=4AB00CE18DCD399736D5AF09C68F13B8

[5] Sheth, A.P., Gomadam, K., and Lathem, J. “SA-REST: Semantically Interoperable and Easier-to-Use Services and Mashups”, IEEE Internet Computing., vol. 11, no. 6, 2007, pp. 91-94

[6] Wikipedia, “Database Normalization”, Aug. 9, 2012, http://en.wikipedia.org/wiki/Database_normalization

[7] Wikipedia, “Data warehouse”, Aug. 6, 2012, http://en.wikipedia.org/wiki/Data_warehouse

[8] Dustdar, S. and Sheth, A. “Services Mashups: The New Generation of Web Applications”, Internet Computing, IEEE, Sept.-Oct 2008, pp. 13 – 15

[9] Durvasula, S. et al., SOA Practitioners’ Guide Part 2: SOA Reference Architecture, Sept. 15, 2006, http://www.soablueprint.com/whitepapers/SOAPGPart2.pdf

[10]  R. Kimball, L. Reeves, M. Ross, and W. Thornthwaite. TheData Warehouse Lifecycle Toolkit. John Wiley & Sons, Inc., 1998

[11] Wikipedia, “Common Object Request Broker Architecture”, July 29, 12012, http://en.wikipedia.org/wiki/CORBA

Enterprise Architecture August 10, 2012

Posted by 3562pittena in Enterprise Architecture.
add a comment

I’ve learned a lot about Enterprise Architecture (EA) so far this lecture. My views on it in the beginning were skewed and I didn’t exactly know what it was. It’s still not 100% clear to me, but I don’t think it will be until I start putting what I’ve learned into practice (if that ever happens).What I have learned about EA is that it is an invaluable practice that should be used by all large corporations. There are many technologies that can support the EA process and having all the stakeholders agree on technologies is the best solution.

Having a common database is a good implementation for EA. Having one location for all of your data allows for easier integration of all the applications that need to get at that data. This allows for organization in the business (less applications/interfaces) as well as easier maintenance. Having a common database shows a maturing EA company. In the four stages of maturity given by Prof. Kaczmarek, it would be at least in the “Standardized Technology” stage.

COBRA is a standard defined by the Object Management Group (OMG). As wikipedia states, “CORBA enables separate pieces of software written in different languages and running on different computers to work with each other like a single application or set of services.” [1] Implementing something like COBRA would increase the EA maturity. It creates better integration and allows for different applications to access the same data. In the four stages of maturity, it would be at least in the “Standardized Technology” stage. As with any standardized technology, making it easy for everyone to interface with removes some of the complexity that can be put in it. In other words, some of the “cool” things that might be able to be done with a single programming language cannot be done using COBRA because it has to implement many different programming languages.

Web-services fall into the same category as COBRA. It defines an interface to some data or an application on a separate machine. It allows for easier integration and less applications in the company. This also falls under the stage of “Standardized Technology”

A Service-Oriented Architecture (SOA) is much like web services, but the entire architecture is all around these loosely coupled web services. The web services should be modular, granular, interoperable and reusable. Moving to a service-oriented architecture would move the maturity of the organization from the “Standardized Technology” state and into the “Optimized Core” state. The organization is moving to a high level business standard and that is why that move takes place.

When you start to get more and more mature, you start to have many different kinds of requests that are being sent over your SOA. An Enterprise Service Bus (ESB) is the model used to implement that interaction. Using SOA with and ESB is increasing the companies maturity. Depending on the use of the ESB, the company may be moved into the “Business Modularity” stage of maturity.

There are many different technologies that can be used to enhance a companies maturity in EA. A few were named here. Any time you can remove the necessity for separate applications and increase the integration of other applications, the maturity of the EA increases.

[1] Wikipedia contributors. “Common Object Request Broker Architecture.” Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 29 Jul. 2012. Web. 10 Aug. 2012.

Enterprise Architecture Session 2 Summary August 10, 2012

Posted by Jiaqi Wu in Enterprise Architecture.
add a comment

IT has become an integral part of every business. However, this technology has a wide variety of effectiveness.

EA Technology August 9, 2012

Posted by brltkd in Enterprise Architecture.
add a comment

There are many technologies available that organizations can use to support their processes and facilitate the efficient use of data. It is important to use standards derived from the businesses strategic goals in both data storage and application development. The specific technology implemented will depend on the organizational structure and the level of development of the systems.

Many companies require the same data for the processes that are performed throughout the enterprise. It is advantageous for these organizations to use a common database to store their information. An example of this type of approach is an electronic medical record system. Medical organizations can vary greatly. There are inpatient units, emergency departments, operating centers, ambulatory clinics, and numerous specialty areas. Each has their own unique processes but they all depend on the information stored in the patient’s chart. Having this information stored in a common database used in all areas makes it immediately accessible to anyone that needs it and in a context specific to their position which improves the overall operation of the organization.

When multiple systems are required to support processes, there must be a method for them to communicate. One technology available to link these applications is the Common Object Request Broker Architecture (CORBA). This architecture allows distributed objects to communicate via an Object Request Broker (ORB) which receives the request from the client, sends it to the object, waits for the results, and returns them to the client [1]. Since CORBA can be implements using a wide array of programming languages it could be beneficial where communication with legacy systems is necessary. Interfaces could be implemented to allow interaction from other systems without the needing to design the applications.

Another technology that facilitates communication between applications is service oriented architecture (SOA). This is a framework for developing applications in pieces where each performs a specific function. One of the important principals of SOA is reusability. A single service can be developed to implement a specific business function. For example, a service that provides contact information for a customer may be developed. Then any application throughout the organization that needs customer information can make use of that service to retrieve the information. SOA helps reduce application development time as well since the main logic defining a process or data access is encapsulated in the service. This allows the developer to focus on the application logic instead.

Web services are an implementation of SOA. A web service is a software system designed to support interoperable machine-to-machine interaction over a network [2]. Services are published on the organizations web server and may allow both internal and external use. Web services are popular for interaction with social media sites like Facebook. Facebook provides services that websites use to pull information from the user’s profile. This allows websites to customize their page based on unique information the user has entered in their profile.

An Enterprise Service Bus (ESB) is a key enabler in implementing the infrastructure for an SOA [3]. It provides support for interaction between heterogeneous services and addresses integration problems that maximize the re-use of services and maintains flexibility [3]. The ESB can combine multiple services as well as other communications protocols like CORBA to provide a single method for communication. All applications communicate via the ESB. It provides the flexibility for disparate systems to work together in a standard manner. This would be valuable in the organization models that want to ensure process standardization.

The exact technology used by an organization will depend on their requirements. There are a lot of options available that can support their enterprise architecture. A shared data source is essential for data integration across the company. Technologies such as service based architectures help ensure standard processes are used to both access and manipulate data.


[1] jGuru.com, “Introduction to CORBA,” Oracle, 2012. [Online]. Available: http://java.sun.com/developer/onlineTraining/corba/corba.html. [Accessed 6 August 2012].
[2] W3C, “Web Services Architecture,” 11 February 2004. [Online]. Available: http://www.w3.org/TR/ws-arch/. [Accessed 23 July 2012].
[3] Microsoft, “Microsoft BizTalk Server ESB Guidance,” Microsoft, 2012. [Online]. Available: http://www.microsoft.com/biztalk/en/us/esb-guidance.aspx. [Accessed 9 August 2012].



TOGAF – An Enterprise Architecture Framework July 2, 2012

Posted by Sapna Sumanth in Enterprise Architecture.
add a comment

Enterprise architecture in basic term means the structure or the blue print of an enterprise. The structure describes the mission, values, the technologies, processes, people, information, underlying IT’s systems, applications and operations. Through Enterprise architecture, complex IT systems can be managed well by addressing the current and the future needs of the organization and also helps in achieving a balance between the business and the IT sides. It is highly important in delivering real business values. People play an important role in any organization. There must always exist collaboration, harmony & integrity. Selecting right people for different job roles is important. As Garter defines it, ”The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment.” [8]

The Open Group Architecture Framework best known as TOGAF, is a framework for EA that is owned by the Open Group. This framework provides a comprehensive  approach, guidelines & supporting tools for designing, planning, implementation and governance of enterprise architecture. TOGAF defines the following:

1. Four Architectures

  • Business Architecture
  • Application Architecture
  • Data Architecture
  • Technical Architecture

Business Architecture: It defines the business strategy, governance & processes that the business uses to meet the goals. The important attributes of EBA are people, financials, organizational structure and processes. The goal of EBA is to ensure that the changes in the above attributes such as people, financials, process and structure etc. are optimized with information and technology, which supports the business strategy [4].

Application Architecture: It deals with the best practices of application design, development & deployment, to meet current and future business needs of an organization. The evolution of application architecture plays an important role in providing greater business value through faster & cost effective delivery of high quality applications, easy integration, improved system performance and low maintenance. Some of the important attributes of any application architecture include application – availability (up-time), agility (ability to change) & scalability (ability to scale up/down). [1][2]

Data Architecture: It defines the organization’s data assets and their management. It focuses on the information needs of the organization to run the business. It deals with how the business information is collected, organized, protected and distributed/shared, using structured data stores such as databases and unstructured data stores such as documents, spreadsheets, presentations etc. [2]

Technical Architecture: It defines the set of technology standards and services for both software and hardware systems, to achieve business goals. It also makes sure that these standards are accepted, embraced and used throughout the organization. The goal of ETA is to deliver products – faster, better and cheaper.  The technology architecture represents the fundamental organization of the computing/ telecommunications hardware and networks. [5]

2. Architecture Development Method [ADM]: It is a detailed approach to develop, implement and govern enterprise architecture such that the business and IT are aligned. It is an iterative and cyclic process. Each step checks with Requirements. [6]. TOGAF ADM consists of eight phases apart from the preliminary phase.

Preliminary phase: This phase describes the preparation and initiation activities required to meet the business goals for the new EA.

1. Phase A – Architecture Vision: This is the initial phase of ADM which includes defining scope of the architecture, identifying the key stakeholders, defining the architecture vision and obtaining the management approvals.

2. Phase B – Business architecture: This describes the organizational strategies, processes, information and geographic aspects of business environments. It is used as an artifact for demonstrating the business value for upcoming architecture work to the key stakeholders and the return on investment (ROI) to those supporting and participating in subsequent work.

3. Phase C – Information systems architecture: This phase involves developing the required information systems i.e., data and application architecture. This describes the enterprise’s IS architecture that will enable business architecture as well as Architecture vision in a way that addresses the request for architecture work and the stakeholders concerns.

4. Phase D – Technology Architecture: This phase develops the target technology architecture that enables the logical and physical application and data components.

5. Phase E – Opportunities and Solutions: This process identifies the delivery vehicles (i.e. projects, programs and portfolios) that effectively deliver the target architecture identified in the preceding phases. These accounts for all the gaps between all the architecture domains and logically group them into work packages within the enterprise’s portfolios.

6. Phase F – Migration Planning: This defines the plan to move from the baseline architecture to the target architecture. The activities include assessing the dependencies, costs and benefits of migration. The objective is to ensure that the implementation and the migration plan are coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio.

7. Phase G – Implementation Governance:  The objective of this phase is to ensure conformance with the target architecture by all the various projects of the organization and to perform necessary governance functions for any implementation of the architectural change requests.

8. Phase H – Architecture Change Management: The goal of this phase is to ensure that the target architecture meets the estimated business value. It also includes managing the changes to the architecture in a cohesive and structured way.

The final step of ADM is the Architecture Requirements Management, which ensures that the requirement management process is standard across all ADM phases.

3. Enterprise continuum: The Enterprise Continuum may be viewed as a “virtual repository” (as of TOGAF 9 this is not virtual any more) of all the architecture assets available to an organization. These include architectural models, architectural patterns, architecture descriptions, and other artifacts. These artifacts may exist within the enterprise and also in the IT industry at large [6]. It includes  – Architecture Continuum and the Solutions Continuum.

Architecture continuum: It comprises of all the building blocks of enterprise architecture starting from the foundation architecture to common systems architecture to Industry architecture until the enterprise specific architecture.

Solution continuum: Solution architecture on the other hand represents the implementation of architecture at each level in detail. It includes Products and Services, Systems Solutions, Industry Solutions and Enterprise Solutions.


[1] Gartner – Defining the Discipline of Application Architecture

[2] Enterprise Architecture Alignment Heuristics

[3] Gartner defines Enterprise Information Architecture

[4] Gartner – Understand Enterprise Business Architecture to Realize Your Future State

[5] Essential Layers, Artifacts, and dependencies of Enterprise Architecture, by Robert Winter and Ronny Fischer

[6] The Open Group Architecture Framework

[7] http://pubs.opengroup.org/architecture/togaf9-doc/arch/toc-pt2.html

[8] http://www.gartner.com/it-glossary/enterprise-architecture-ea/

A Glimpse at the Discipline Known as Enterprise Architecture June 30, 2012

Posted by daleklein in Enterprise Architecture.
add a comment

Gartner is a leading information technology research and advisory company and we start with their insightful definition as to what is enterprise architecture.  “Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.  EA is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.” [1]

One of the key components of enterprise architecture is that it is a discipline that includes people, processes and technology of the enterprise as well as their relationship to one another and the external environment.  To that end we will take a glimpse at a key factor to the success of implementing EA which is the alignment of IT and business.  Next we will look at operating models which provide us with an abstract representation of a business entity and how it operates across processes and technology domains across the entire organization. In closing we will touch on architecture blueprinting which is a discipline that helps organizations define and deliver technology capabilities that are aligned with their strategic objectives.

Business managers are interested in knowing how any IT initiative will add value to the business organization.  In communicating with these executives you need to understand their vocabulary and communicate in their language in order to remove obstacles that might undermine the process.  EA needs to provide consistency through the use of standards or best practices which in turn reduces the total cost of ownership.  Good alignment with the business is important, but the question we need to ask ourselves is does it translate into real dollars?  According to the 2008 “State of the CIO” survey it couldn’t be clearer: Alignment brings the money.  According to results from this survey “CIOs who said they were aligned with the business reported that IT had enabled a new revenue stream more than twice as often as those CIOs who said they were not aligned (24 percent versus 11 percent). More important, more aligned CIOs said they had used IT to create a competitive advantage for the company than unaligned CIOs (38 percent versus 23 percent).” [2]

Aligning your IT projects and processes with the business’s strategies is a risky undertaking. It puts the IT department on the front lines of doing battle in the marketplace, where failure is common. This is why the aligned organization’s top executives must create a supportive environment in which the CIO and other managers recognize what isn’t working and can quickly adjust the plans.  A supportive environment is one that does not punish people for every failure which leads to a corporate culture of playing it safe and finger pointing when things go awry. [3]  In order to build an effective alignment between business and IT you need to build a high trust level between the two divisions.  If you have a supportive corporate culture you will build higher levels of trust and view the other side as a partner or a team player that just plays a different position than you.

The next thing we want to take a glimpse at is a framework that will give us a better understanding of how the business works.  An operating model provides us with an abstract representation of a business entity and how it operates across processes and technology domains across the entire organization. [4] It is typically used to create a framework which helps formulate a strategy or a strategic scheme which will support integration while providing value to the business organization.  It is the primary driver of the level of standardization and data sharing.  There are four different models which can be applied – coordination, unification, diversification and replication which will look at independently.

A company that needs a low degree of standardization but will have high data sharing is considered a “coordinated company”.  These types of companies will have a number of representative locations and they may offer a number of varying services, probably in different ways, but they need access to the same core data source relating to their customers.  A prime example of this is your bank.  Your data should be the same and accessible to any branch of that bank you happen to visit.  There is no unified process because not all branches offer the same services or level of service which is dependent upon its size and location.

A company that needs a high degree of standardization and will have high data sharing is considered a “unified company”.  This is a case where the business shares its core processes while needing access to the same data.

A company that needs a low degree of standardization and will have low data sharing is considered a “diversified company”.  This is a complete opposite to the unification model.  You typically have multiple business units which make up the organization, they probably have a different set of customers that are focused on and there really is no overlap in their functions.  They do not have the same customer so there’s no need to integrate the data and while processes may be similar they are usually tailored to the individual units of operation.  This model is often used by aerospace and defense contractors.

The last glimpse into the world of Enterprise Architecture will be to look at blueprinting.  This time we look to the insightful interpretation of Deloitte Consulting LLP for a definition on blueprinting.  They state “Enterprise Architecture Blueprinting is a discipline that helps organizations define and deliver technology capabilities aligned with their strategic objectives. Blueprinting is a process of progressively elaborating a set of capabilities through conceptual, logical and physical states, informing decision making at multiple levels, and helping to maximize the business value of technology.” [5]

Blueprints are used to align a business’s assets, processes and capabilities to the strategic objectives of an organization.  It accomplishes by assessing the current state of its technology components.  Once that is realized it can map out a future state of capabilities and processes. A roadmap helps to deliver the future state into the current state.  The blueprints are tools for turning large and complex concepts into details that will assist in decision making.  By giving the stakeholders a view of the landscape they can better drive the strategic alignment of technological capabilities.

Enterprise Architecture Blueprints should be agile and they should be evaluated and updated at regular intervals.  As technology milestones are achieved, current-state models should be versioned to reflect new capabilities. As business strategies change, future-state diagrams should be updated to ensure that the represented mix of capabilities and processes support the new direction. [5]

“Organizations that institute the appropriate governance and processes to maintain their Enterprise Architecture Blueprints also benefit from having a tool set to gauge the impact of changes to business strategy. Having up-to-date representations of organizational capabilities and processes, mapped to strategies and KPIs, allows for situational analysis to be performed; the impact of strategic changes to people, process and technology can be meaningfully evaluated when Blueprinting models are kept current in organizations with mature Enterprise Architecture functions.” [5]

As a final note it is worth noting that in the 2010 State of the CIO Survey that when asked what CIO’s were focusing their time on we see the following: “Aligning IT initiatives with business goals (58 percent), improving IT operations and systems performance (53 percent), and implementing new systems and architecture (47 percent) are among the most frequently cited activities that best characterize where CIOs spend the majority of their time and focus.” [6]

Works Cited:

[1] “Gartner IT   Glossary,” [Online]. Available:   http://www.gartner.com/it-glossary/enterprise-architecture-ea/. [Accessed 25   June 2012].
[2] A. HOLMES, “The   ROI of Alignment,” bITa Center, 2008. [Online]. Available:   http://www.bita-center.com/node/310. [Accessed 15 June 2012].
[3] K. Burger,   “Developing a Corporate Culture for Better Business/IT Alignment,”   Insurance & Technology, 8 May 2011. [Online]. Available: http://www.insurancetech.com/management-strategies/229402723.   [Accessed 15 June 2012].
[4] “Wikipedia,”   [Online]. Available: http://en.wikipedia.org/wiki/Operating_model. [Accessed   26 June 2012].
[5] “Enterprise Architecture Blueprinting: Road Maps for Strategic   Alignment,” Deloitte Development LLC.

Enterprise Architecture and Software Platforms June 29, 2012

Posted by Jiaqi Wu in Enterprise Architecture.
add a comment

Rarely do we find an entire company operating under an incredibly organized premeditated Enterprise Architecture (EA). The easiest way to organize a company is to divide it between products. A team is responsible for its own product and nothing else. However many products within the same company are related to the same field. As an example, GE Healthcare develops numerous medical imaging products. As an imaging device, the human interface contains a lot of common inspiration. However as products are developed by separate teams, each team must in the end develop its own version of the software. Management wise, this makes things very easy. Every product does not depend on the status of any other product. However this is not the most efficient way. There is a large piece of architecture missing in this methodology.

In order to develop software in a way such that it is accessible throughout the business, a different framework needs to be used. This must become part of the Enterprise Technical Architecture (ETA). Service oriented architecture (SOA) is becoming increasingly popular. New frameworks available that enable this type of software architecture are becoming more widely available. SOA enables the development of software platforms which are much more flexible and maintainable than applications with specific purposes.

(The concept of platforms vs applications is a long discussion in and of itself. An informal post by Rip Rowan https://plus.google.com/112678702228711889851/posts/eVeouesvaVX illustrates the importances).

The common software platform in a business is a necessary step in order to increase efficiency of the business processes. As a software business, it is necessary to develop software as quickly as possible and have it be as maintainable as possible. To make that happen, common software platforms must be developed. The coordination effort here is in the Enterprise Architecture. Specifically, this needs to occur in the ETA, EIA, and EAA layers.

  • ETA – has already been described above. Frameworks must enable simple development of components to a platform.
  • EIA – The platform must allow access to the information layer. To be efficient, standard practices such as database normalization must still be in place. These are fundamental requirements and are out of the scope of this article. More importantly, heuristics should be used between components of the platform and IT in order to ensure better IT alignment [1].
  • EAA – The platform components must be developed. These include services that allow access to all of the information as well as basic functionality that is common across the business. Applications are then developed by calling components of the platform. Each product team can develop and manage its own software at the application level.

These three layers will enable more efficient software development. In the end it will aid the business processes in the EBA layer. The goal will always be to make the business more efficient. If a technology does not help the business, it serves no purpose in the organization.


[1]            Pereira, Carla. Sousa, Pedro. “Enterprise Architecture: Business and IT Alignment.” 2005 ACM Symposium on Applied Computing.

[2]            Stevey’s Google Platforms Rant. https://plus.google.com/112678702228711889851/posts/eVeouesvaVX. Retrieved on 28 June 2012.

IT: Everywhere, but invisible June 28, 2012

Posted by danthomas3 in Enterprise Architecture.
Tags: , , , , , , ,
add a comment

I’ve heard many stories from IT professionals who have worked for organizations or businesses that have evolved a sense of complacency with the proposition of their IT operations being “everywhere, but invisible”. IT governance reserving the term “invisible” to suggest that all IT operations (including application development, data security, server maintenance, etc.) be helpful but nonintrusive while “everywhere” simply acknowledges the growing global reliance on the digital tools that IT can deliver. “Everywhere, but invisible”, I cringed every time I heard this phrase. Admittedly, it’s a phrase that could be descriptive of many clerical departments within an organization or business, but IT professionals have the potential to be valued with the same (if not more) importance as high level executives. There are perhaps many ways to justify this inflated importance but it requires evolving services beyond the minimum purview of simply writing computer code or answering Help Desk calls all day. It’s been my experience from working in the industry that when this is perceived of IT, the department merely shrinks in size and respect garnishing little to no clout and powerless and speechless within circles of discussion pertaining to business growth and innovations. There is much value for organizations and businesses from IT operations when it strategically aligns people, processes, and technology using enterprising architecture to promoting more growth of strategic initiatives [2].

Enterprise Architecture requires an coordinated operational model of rigorous architecture of a business’s core processes prioritizing customer interfaces, decentralized enterprise data, and business strategies while showing how these processes are unified, diversified, replicated, or coordinated [1, 2]. Standardizing business processes includes infusing an organization’s overarching scope and objectives to operational process and is invaluable in blueprinting business strategies. Standardization also shows how adaptive and supportive IT can be enabling organizational growth. As with any architectural design, customization for the proper audience should be considered when delivering representation of IT deliverables. Architectural models should be skewed for the proper audience; business models should be distinguishable from models of information or data flows and technical models considering the diversity of skillsets [3]. I’d have to admit that my experience thus far in IT coupled with the theories of Enterprise Architecture empowers me to implement agile and well-planned modeling delivering a contextual message of justifying how IT is more valued by its invisibility rather than dispensable, capable of not only aligning technological operations but potentially enhancing many, if not all, business and organizational processes. Enterprise Architecture allows IT to truly be everywhere and invisible.

[1] Enterprise Architecture – Operating Model.pptx
[2] Enterprise Architecture – Foundations.pptx
[3] Zachman, J.A., Framework for information system architecture

Enterprise Architecture June 28, 2012

Posted by mattpassini in Enterprise Architecture.
add a comment

The cross between software design patterns and business models

It is often hard to succinctly summarize any newly accepted term which defines a range of generally accepted best practices, especially when it transcends multiple organization units and incorporates the enterprise as a whole.  Perhaps it is easier to start with different perspectives.  A software engineer may relate to the generalization that Enterprise Architecture (EA) is similar in nature to software design patterns, but it applies to not only software, but the entire set of processes for each business unit as well.  From a business analyst’s point of view, it may be easier to relate it to a business model, but one that not only focuses on processes but also on the alignment of those processes to the software and technical infrastructure which supports it.

While neither of these simplifications is completely accurate, it helps create a mindset for understanding one of the widely accepted definitions of EA, which is, “Enterprise architecture is the process of translating business vision and strategy into effective enterprise change” [1]. However, it is important to understand that the goal of EA is not to simply create an end product, but to continually set the strategic goals that drive the business forward.  The separate organizational units must take these goals, utilize the architecture that EA has set forth, and align themselves with the other organizational units to create one unified and aligned business that is agile, effective, and efficient.

One of the most important aspects of EA is the alignment between the business units and the layers of EA.  While there are differing standards for the number of layers to EA, although generally limited to 4 or 5 [2], I prefer to view it as three essential layers.  This perspective is my own and differs from most of the research and standards that are available.  The three layers I select to reference are the Business Architecture, Information Architecture, and the Technology Architecture layers.  However, some models break the Business layer into process and integration, and most also subdivide the Technology layer into software and infrastructure.  From a high level perspective, using only three layers allows for easier alignment between the architectures.  This provides a bit of abstraction and allows for the organization units to subdivide their associated layers, which allows for easier and more simplistic alignment at a more granular level.

To me, the most important alignment is that between Business Architecture and Technology Architecture, specifically the software.  The purpose of Information Technology is to support the business practice [3].  However, many times IT professionals forget their main objective and veer off course.  When this happens, IT, and more specifically, the software architecture, becomes misaligned with the business architecture, and the business begins to slowly lose that agility, effectiveness, and efficiency.  This misalignment can be caused from day one by leaders who are not cognizant of the necessity of EA and alignment, or more likely, through many decades of incremental changes.  These incremental changes often slowly contort the original application architecture, and if a continual EA process is not in place to immediately catch and rectify the issue, the alignment will only continue to worsen.  There are four key heuristics that can be used to measure the alignment between business architecture and application architecture [4]:

  • Each business process should be supported by at least one application system
  • Business process tasks should be supported by a single application.
  • Critical business process should depend on scalable and available applications.
  • Each application system functionality should support at least one business process task.

Many organizations have been informally practicing the majority of standards that EA provides.  However, formalizing these standards and creating an EA team in the organization can be essential to properly aligning the business. While EA may be the most helpful to larger organizations, smaller companies should acknowledge the need for immediate alignment.  As smaller companies grow into large companies, it is far too easy to forget the alignment issues and blaze forward in an unsatisfactory fashion.  It is essential to remember that EA is not a product, but a process, continually mapping the current architecture, where the business wants to be in the future, and providing a solid road map for getting there. This should be done through standard measurement processes, including defining metrics a priori and testing them continually during development and after implementation.  Lastly, effectively communicating these results not only to the EA team but to the entire organization helps everyone understand the benefits of EA and creates a consistent understanding of the motivation, goals, and successes or failures.

[1] Gartner Clarifies the Definition of the Term ‘Enterprise Architecture’
Published: 12 August 2008 ID:G00156559

[2] Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, Robert Winter and Ronny Fischer, Journal of Enterprise Architecture, May 2007

[3] Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology, Fred D. Davis, MIS Quarterly, Vol. 13, No. 3 (Sep., 1989), pp. 319-340
Article Stable URL: http://www.jstor.org/stable/249008

[4] Carla Marques Pereira and Pedro Sousa. 2005. Enterprise architecture: business and IT alignment. In Proceedings of the 2005 ACM symposium on Applied computing (SAC ’05), Lorie M. Liebrock (Ed.). ACM, New York, NY, USA, 1344-1345. DOI=10.1145/1066677.1066980 http://doi.acm.org/10.1145/1066677.1066980

Enterprise Architecture June 27, 2012

Posted by brltkd in Enterprise Architecture.
add a comment

Companies are always interested in ways to grow their business and overall create a better product for their customers. The business needs to be able to respond to changes in areas such as market forces, the economic climate, and regulatory requirements. This is easier to achieve when all aspects of the business are working together towards a common goal. One method to guide the organization through these changes is to develop an enterprise architecture.

“Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key requirements, principles, and models that describe the enterprise’s future state and enable its evolution” (Lapkin, et al., 2008). This definition of enterprise architecture reflects concepts that essentially every business wants to maximize. However, creating an enterprise architecture for an existing organization may be a daunting task.

Companies are grown incrementally. “When entrepreneurs first sit down to hammer out the business plan for a new venture, they would never dare to have the hubris to architect an organization large enough to be considered an enterprise” (Bloomberg, 2011). Instead they start with the systems and processes they need to run the company. Then, over time, additional systems and procedures are created as needs arise. This can create a patchwork of disparate systems and processes that may be inefficient or redundant. The goal of the enterprise architecture is unify and integrate these business processes and the data.

Fortunately many of the concepts within enterprise architecture are logical points that business may gravitate towards even without establishing an enterprise architecture. We have not established an enterprise architecture at my organization. However our medical records system employees many of its techniques. The primary business function is to provide health care to patients. All aspects of the system are designed to support that goal. It’s based on a single repository of data so the information is available across the enterprise. The same data source is used for both patient care and business functions like financials. As an academic medical center, research is critical. Data warehouses driven by this information are used to support that function.

The system is also built modularly which provides great flexibility. There is a myriad of laws and regulations that we must comply with in healthcare. Meaningful Use is one of the most recent regulations that we have to comply with. One of the required core measures established for stage one is the ability to electronically exchange information with at least one other organization (Center for Medicare & Medicaid Services, 2011). We implemented a new module which integrates this capability into the standard workflows in most of our clinics. Our agility enabled us to meet this and nineteen other objectives making us part of a minority of hospitals that qualified for Meaningful Use in the first year (Terry, 2011).

These are examples of how technology supports the business vision and how its flexibility can enable rapid change. However, true enterprise architecture goes far beyond the technology infrastructure. “The scope of the enterprise architecture includes people, processes, information and technology of the enterprise” (Lapkin, et al., 2008).

Enterprise architecture really needs to look across the whole organization. It establishes a plan to ensure everyone is working to advance the businesses strategic goals. As I illustrated earlier, some areas may already be using elements of enterprise architecture. “If some group is already architecting within a constituency, then the enterprise architecture focus should be on interfaces or connections, or dependencies between that constituency and other with which it must work” (Robertson, 2009). Rather than working in silos, the enterprise architecture enables cross-divisional collaboration. It needs to take advantage of the architecture already developed and validate they align with the business vision. Then these resources can be shared which ultimately leads to a more efficient business.

Enterprise architecture describes the organization’s desired state and guides it toward that goal. However we must remember that a business is never static. As the company approaches the defined goal, the enterprise architecture itself must be flexible and adjust to allow continued growth. This planning helps the organization embrace changes and adapt to the challenges it encounters.

Works Cited

Bloomberg, J. (2011, April 5). Why Nobody is Doing Enterprise Architecture. Retrieved June 25, 2012, from zapthink.com: http://www.zapthink.com/2011/04/05/why-nobody-is-doing-enterprise-architecture/

Center for Medicare & Medicaid Services. (2011). Eligible Professional Meaningful Use Core Measures Measure 14 of 15 Stage 1. Washington DC: Center for Medicare & Medicaid Services.

Lapkin, A., Allega, P., Burke, B., Burton, B., Bittler, R. S., Handler, R. A., et al. (2008). Gartner Clarifies the Definition of the Term. Stamford: Gartner, Inc.

Robertson, B. (2009). Why Do Enterprise Architecture? Stamford: Gartner, Inc.

Terry, K. (2011, October 24). Hospitals Move Slowly on Meaningful Use. Retrieved June 25, 2012, from http://www.informationweek.com: http://www.informationweek.com/news/healthcare/EMR/231901531



Enterprise Architecture: A Case Study from Software Development June 26, 2012

Posted by 8952chavezr in Enterprise Architecture.
add a comment

As a software engineer, it’s interesting to see the choices that the business and IT make with regards to the tools we use throughout the development lifecycle of our products.  I work for one of the largest software development companies in the world.  However, the IT infrastructure that supports the developers does not always seem to portray that fact.  Teams across the organization use different sets of tools to accomplish the same things, such as requirements and defect tracking, integrated software builds, document reviews, code analysis, etc.  Although the products the teams are developing are very different, the process is the same and the teams have the same needs in adhering to the process.  With Enterprise Architecture, the organization can support established processes and help grow the processes to be more efficient.

As described in the Gartner report “Guide for Determining EA Business Value,” Enterprise Architecture has to consider both short-term and long-term results.  In our case, it seems that many of the decisions were made for the short term to help support new processes.  A need arose, and someone made a decision to solve it without much thought to the future.  For example, teams throughout the organization are adopting the Agile methodology for developing software, and there are many tools that support this effort such as Rally, Scrumworks, TargetProcess, VersionOne, XPlanner, etc.  The issue here is that the effort to adopt Agile rose up from the individual teams and only now is leadership paying attention.  Because leadership has vision across teams, it is up to leadership to take notice of the individual efforts and harness it to standardize the set of tools.  More importantly, leadership needs to understand from where new trends arise to stay ahead of the engineering teams or at least on the same track.

Slowly, leadership is making strides toward this goal.  They have realized that the application landscape is too wide-spread.  This is insight an application blueprint as described by Rohloff can give us.  Knowing what applications are in use by different teams, they can understand how best to proceed.  Many of the tools used in Agile planning and execution are very similar.  Each team will have preferences, but EA needs to take a larger perspective.  It is not just about what need the tool fulfills but what other problems it can help solve.  IT and business leaders should analyze opportunities for integration so the tool builds up the data landscape.  This way, the tools can deliver much more than data.  They can deliver information such as where teams spend most of their development time (documentation, coding, fixing defects, etc.) or how the process can be changed to better suit our needs.

In the case of the software engineering teams, the organization has already defined processes to help develop software in a regulated industry.  The process is robust but it is based on the waterfall approach to development.  It needs to adapt to the Agile methodologies that teams are implementing.  This will affect many parts of the organization and is a great place for Enterprise Architecture as described by Gartner to step in.  Although much of the friction in adapting our process to Agile manifests itself at the application level (e.g. the requirements tool is too strict and doesn’t let us refactor requirements easily sprint to sprint), Gartner understands that the engineering leaders and IT first need to understand the business, the information, and the technology approaches before prescribing applications.

In terms of the Enterprise Business Architecture, the organization has already started to change how people are organized and how the different groups such as engineering, quality, validation, and support interact.  Some groups are more integrated than others, but still there is plenty of work to be done on the process side.  For example, teams are still trying to figure out what tools should be used for tracking defects and how defects fit into the Agile process.  The teams need to figure out and leadership needs to guide them how to make sure defects are given the proper attention in the fast paced attempt to deliver new and better features.  This means support and quality need to work closely with engineers to find the source of defects and track the progress of the fix within the Agile paradigm.  As the process matures, leadership needs to make sure that teams adhere to whatever is decided and that the teams are properly trained.  With the business aspects in place, only then can teams begin to form technology and information architectures that support the business people, organization, and process.

In terms of the information, leadership needs to define the data that are critical to running Agile projects throughout the entire life of the product.  At this point, they have identified metrics, which is a good start.  However, it is still not clear if everyone truly understands what the metrics mean.  This is a miss in the business architecture.  The process is not clear.  Also, the information model needs to be put into perspective so we know how different parts of the organization interact with it.  In terms of technology, we need to identify a common platform that can be used across engineering teams.  This will save the IT department time and money because it is clearly easier to maintain a common set of tools than a whole host of different ones.  That is, when the tools are adaptable to different technology stacks that the engineering teams use for development.  Given these three pieces (business, information, and technology), IT can begin to develop applications that can bring the pieces together to support the process and help it mature.

For example, many teams in our organization use Hewlett Packard’s Application Lifecycle Management tool to track requirements, test coverage, and defects.  There are other teams that use other tools, but the leadership is moving towards HP.  In terms of the Agile process, leadership is leaning towards Rally, and they are investigating how to integrate Rally and HP to improve the process around tracing requirements and defects to user stories and combining metrics around coverage and team velocity.  They are even working with Rally developers to leverage the HP APIs to tap into the data.

In bits and pieces, the IT and leadership teams seem to be moving in the right direction.  However, there is more focus on the technology than on the business architecture or the information architecture.  Without those, we can only go so far.  In this case, IT will only be a set of applications we use instead of an agent for change.  Still, it is a difficult task to develop and roll out new processes when teams are still expected to deliver on commitments.  In Agile circles, many experts tell teams that adopting Agile will feel slow at first but not to be discouraged.  I believe this goes for EA as well, which is why we need to understand short-term and long-term goals.  We can use EA to support the change that is taking place regardless of EA efforts, but we must also figure out how EA can take control of the change and help guide it in a more manageable fashion.