Is SOA of interest to a Data Architect?

This question came up recently on one of the forums I subscribe to and piqued my interest.

Whether Service Oriented Architecture (SOA) is specifically of interest to a Data Architect depends on what type of Data Architect you aspire to be.

There are at least dozen easily identifiable variations that all revolve around the definition and processing of data but require different skill-sets. However the main differentiating factor, for me, is whether the Data Architect is primarily interested in producing architectures for persistent data storage or transient data processing.

I do data processing but I know quite a few Data Architects that focus solely on designing and building databases and data centres for persistent storage but with little interest in what the data is or what it’s used for.

For this type of Data Architect it's all about infrastructure and technology , i.e. they are mainly interested in technical issues such as availability; backup & recovery; security; hardware performance and a bucket load of similar things to do with infrastructure and focussing on the stuff that is physically deployed to support the data repository.

For a Persistent Storage Data Architect I'd say that SOA, like pretty much any other secondary architectural framework, will add little benefit other than intellectual interest.

On the other hand, assuming it’s data processing type of Data Architecture that’s of interest, then it's important to establish the type of data processing environment that you're going to focus on e.g.:

• What type of activity profile is required? Is it predominantly:
  
  
  
  • On-Line Transaction Processing (OLTP), typically characterised by high-volume short duration activities, such as a retail operation or financial markets trading.
  
  
  • Decision Support (DSS or BI) focussing on analysis and reporting against historic information.
  
  
  • Data Warehousing focussing on the long-term archiving of masses of company information for posterity.
    
• What type of process distribution is being supported i.e. is it:
  
• A "Centralised" environment where each business activity is executed against a single centralised data repository.


• A "Federated" environment where a single Business Activity potentially draws information from multiple physically separated sources and merges them together in order to carry out the activity.


• A "Distributed" environment where the multiple implementations of the same Business Activity may be executed in a number of different venues based on some external constraint such as geographic location or line of business.

Although these different data processing environments may all be implemented using the same technology platform (e.g. Oracle or SQL Server could be used as the DBMS or Java as the programming language in all cases) they have different non-functional profiles.

For example, OLTP is "high volume / short transactions" but DSS is "low volume / long transaction" processing or Federated data requires two-phase commit but Centralised data doesn't.

Now if we look at the underlying principles of Service Orientation then I'd say that SOA really only lends itself to OLTP and Federated / Distributed data processing environments (which is where all the fun really is) and, if that is the type of data processing environment you're trying to design then an understanding of Service-Orientation (if not SOA itself) is essential.

For SOA the key principles that are very, very important include:

• Location Independent - i.e. the relationship between client and service are irrelevant),
• Stateless - the Service Provider has no memory of any previous invocations of the Service and once completed (either successfully or otherwise) the previous state of the data environment is discarded. In other words all Services are single-phase commit and do not wait for separate acknowledgement from the Service User.
• Idempotent - a Service can be called repeatedly without side effect for any previous or subsequent invocation.
• Loosely coupled - the Service User only uses the parts of a Service that it needs and ignores everything else.
• Dynamic - the characteristics of the Service being called can change between service calls and it is the Service Users responsibility to maintain compatibility with the Service Provider.

There’s a lot that can be learnt by understanding those principles irrespective of whether you’re ever going to operate in a SOA environment.

Of course, if you’ve done any serious structured systems analysis (e.g. SSADM, OOA&D etc) then most Data Architects will probably have all the basic knowledge required to get by in a Service Oriented environment without too much effort because the art of Analysis & Design doesn’t significantly change no matter what is being deployed.