jump to navigation

August 10, 2012

Posted by 8952chavezr in Enterprise Architecture.

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



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: