In the first installment of this series, I provided the following definition for service-oriented architectures (SOAs): SOA refers to the use of loosely coupled services that are built to provide re-usable business processes that enable the communication between systems and the creation of entire applications within an organization. These services will typically pass data back and forth as they perform some predefined common process. The process could be as simple as basic data movement or much more intricate data transformations, data cleansing or the use of many services to create a multistep, complex process.

Defining an organization's common re-usable business processes isn't as easy as some may think or as vendors may portray. Indeed, the vast majority of SOA vendors simply assume that this process has been completed and that they can just walk in and start building an SOA architecture.

Recently, a multibillion-dollar government supplier was having an IT vendor day where they invited 20 IT vendors to  present their software or services. This large government supplier received more than 300 requests to present at this event. EWSolutions was one of the firms they selected. During the course of the day, each vendor was allotted 20 minutes to explain who they are and what they do. Most of the chosen vendors were software vendors whose core business is based on SOA: SOA testing software, SOA message brokers and so on. We were literally the only vendor that doesn't focus on SOA who was invited to present.

On the day of the event, I had the opportunity to hear three vendor's presentations. I noticed an interesting and subtle theme. As each vendor spoke of the magic of SOAs and how they could revolutionize the government supplier's business, they all said, "Once you've defined your centralized processes and you have a catalog of your data, then we ... (insert specific vendor's pitch)." When it was our turn to present, I begin by saying that we are not an SOA company per se, but you know all that "stuff" you need to do before you can implement SOAs? We do that stuff.

Metadata management with a supporting managed metadata environment is a required precursor to any significant enterprise SOA effort. In fact, it is impossible to create centralized, enterprise-wide processes when you don't have metadata on your systems, process and data.

Before I can discuss how to create common processes, you need to first understand some basic IT terminology, specifically, terms such as system, process, data and business rules. Figure 1 illustrates the interrelationships between these concepts.

Figure 1: IT Component Relationships

System is a term that the vast majority of IT professionals believe they understand. Why wouldn't they? They have probably worked on dozens of individual applications. However, having had the experience of bringing a group of IT professionals together to write an enterprise definition of what a system is was quite revealing. Invariably, people just keep naming systems within the company, as opposed to defining what "system" actually means. It turns out that a system is "a collection of processes with arbitrary beginning and end points." An order entry application is most likely connected through interfaces with many other systems. At what point does each system begin and end? This is something that someone decides. In other words, it is arbitrary.

A process inputs data from a source or creates the data itself and performs a designed sequence of tasks on the data, which it then outputs. These tasks can include transformations, data derivations, data movement, calculations, formulas and other data processing-related activities.

Data consists of numbers, characters, symbols, images, audio, video and other information that represents a specific meaning.

Business rules come in many flavors and varieties. For the purpose of this column, I will only discuss their uses in processes and data. Business rules in a process refer to quality rules, tasks, definitions and constraints that apply to the data within the process. Business rules for data include domain values, definitions, data heritage and data lineage. For example, suppose that you have a process that calculates order cost. There would be business rules around the entire process. The rules may state order_cost = ((product_quantity x product_cost) + order_tax + shipping). Within this rule there will be business rules that govern the data elements, so product_cost must be in U.S. dollars, numeric and a positive number.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access