Information-Oriented Architecture (IOA)

Posted in SOA by AST on Saturday, April 8th, 2006

Amoxil Generic Buy Clarinex Online Neurontin Without Prescription Topamax No Prescription Soma For Sale Glucotrol Generic Buy Aricept Online Stromectol Without Prescription Lotrisone No Prescription Celexa For Sale

If developing a solution architecture around services gives you a service-oriented architecture (SOA), then developing a solution architecture around information should give you an information-oriented architecture (IOA).

Why IOA?

I’ve been giving a lot of thought recently to the concepts and application of service-oriented architectures as part of the U.S. Government’s Service-Oriented Architecture Community of Practice (CoP). The CoP is made up of some really smart people (smarter than me!) who are trying to determine the best way to apply SOA to E-Government in the U.S. The current discussion has been around how best to demonstrate the capabilities of SOA so that it is clear that the technologies exist and they are interoperable. The demo is supposed to be given at the upcoming SOA for E-Government Conference on the 23-24th of May. Doing he math, that doesn’t really leave us much time.

This experience has given me a chance to think about SOA both from the perspective of applying WS-* (this is looking like the platform of choice at the moment), but also from alternative perspectives based on extending the idea of SOA to a community (see Aldo de Moor) and including other disciplines like Knowledge Management (KM).

Last night I spent some time trying to turn the current proposed CoP demo specification into some essential requirements that were independent of technology. Then, having identified some good candidates, tried to look at it from a different perspective to see how you might approach the problem in a non WS-* way, to prove that the technology wasn’t the important part of SOA–one of the big things that we’ve been discussing for the last few weeks. This morning, after having a couple of epiphanies about SOA around thinking about the question “what moves in an SOA?”, I wondered if I could turn the demo scenario (standard buyer/broker/seller) on its head. The result is what I’m calling an information-oriented architecture.

What is IOA?

It really comes down to what you care about. I’m really only starting to understand a little bit about KM, but what is clear is that without information, there’s no way you can create knowledge. If you really look closely at the foundation of SOA, the service, what are its two most important aspects?

  1. how you invoke it, and
  2. what it does

This is what you care about. Yes, you need to probably give it some data to work with, and, yes, it will probably spit something out if it works, but that’s not what you’re mainly interested in. You’re really interested in those two aspects.

However, if you turn it on its head and focus on the information, the questions of invocation and function don’t really matter that much. What matters is what the information is. If you think about a community, you can think about both of these aspects as well. On one hand, you have the potential capabilities of the community for action, but on the other hand, you have the sum of all of the information of the participants. If you are concerned about buzzwords like “agility” and “interoperability”, these imply one crucial facility: adaptation to one’s environment. Which of capabilities or information then have the greatest influence on adaptation?

By definition, SOA is about doing. It provides a set of capabilities and behaviors at a point in time. I posit then that IOA is about being. IOA provides information to be acted upon, not a set of actions to be requested or used. It says, “This is what I am; make the most of it.” This approach provides freedom to the community to make use of that information as it sees fit. It encourages collaboration and enrichment of this information for the good of the community not through what it can do (representing the needs only at a fixed point in time), but through what it is at any point in time. This ever-growing pool of information provides the basis for the community’s collective knowledge, allowing it to use it in new and creative ways as the environment changes.

Applying IOA

I don’t claim to have this all figured out yet, but I’ve been toying with applying IOA in terms of the CoP demo. Maybe if I get it sufficiently coherent, I’ll post it or at least go into it in more detail, however at the moment it’s not complete. Still, I think there’s some lessons and possible approaches.

Recapping that services are primarily about the interfaces and what they do rather than the information they require or produce, what does it mean to apply IOA to solving a problem? The first thing is focusing on the information instead of the interface and function. At this point, I think this concept is ultimately what Fielding is talking about with REST. REST is very powerful (it being the basis of the Web), but it is only an architectural style. It does not represent a concrete architecture. Using REST alone does not give you a complete solution. You still have to apply constraints, rules, contracts and agreements in order to build things with it.

REST is therefore the basis of IOA because it provides some convenient, built-in capabilities if you use HTTP. This choice allows you to focus on the representations instead of how you get to them. In the case of IOA, these representations are specifically limited to information that is useful to the community. The contracts and agreements within the community may also be information that is part of the community, so there is an aspect of recursive definition at play. Because the community depends on more than REST, it is important to note that REST alone is not IOA.

If IOA is primarily about the information contained within a community, there will likely be some impedance in the way that information is represented. For the community to truly leverage this information in new and interesting ways, there needs to be some way to represent it unambiguously. Based on what little I understand, this is where ontologies fit into the picture. We aren’t talking about relationships between these “pure” or “standardized” representations, we’re just talking about the essence of the representations that may be used in a consistent manner. Applying meaningful relationships is where you start acquiring knowledge, but you can’t do that if you don’t understand what you’re talking about.

Back to our happy little buyer/broker/seller scenario, it would seem then, that the role of the broker is a bit different than it would first appear. The value proposition of the broker in this case is not simply mediating between buyers and sellers, it is in how well it can determine and relate the information that each possesses. If a buyer has a shopping list, but the manufacturers don’t understand it, both parties lose. It isn’t that either one is right or wrong, it’s just that they don’t know they’re capable of making a business transaction (anyone who has tried to buy something in a country where they didn’t speak the language understands this issue very well).

Looking at it this way (to me at least), you’re about as far away from service interfaces, objects and functions as you can possibly be. The buyer has information: these are the things I need, the seller has information: these are the things I have, and the broker can “understand” (and I use the term somewhat loosely) that they are talking about the same things. Actually making the purchase requires transmission of more information, but only into a known location. In this case, you can represent this transaction using HTTP verbs, but that’s just an example. You can also represent this transaction by “the user enters their credit card details into the browser and presses ’submit’”. In both cases, the same fundamental information has been exchanged between the buyer and the seller (or the broker acting as a seller and aggregating other sellers ad nausium).

Maybe this is really what the semantic web stuff is about. I don’t claim to know hardly anything about it, because I haven’t had much chance to get into it. However, based on recent interactions with members of the CoP, additional communications with Paul Prueitt and Dick Ballard and lurking a bit on semantic-web, the above all sorta makes a weird kind of sense.


  1. Paul Prueitt said,

    April 8, 2006 at 7:37 pm

    Nice synthesis…additional comments on this is at

  2. AST said,

    April 9, 2006 at 9:26 am

    If anyone is interested in a bit more follow-up on this topic, there was an email exchange between Ken Laskey and myself based on his thoughts. Maybe it will help explain things a little better, but it may get into even more unstable territory.

  3. Greg Lomow said,

    April 10, 2006 at 1:01 pm

    Hi Andrew
    You make some excellent points. Here is my perspective. Pretty much every system we deal with in the Public Services arena (and financial services, commercial servies, etc) is made up of three fundemental building blocks

    *) Information - what data/info/knowledge does some need to get their job done or produce some valuable business outcome.
    *) Services - what are the operations that can be performed on that information to manipulate it, share it, transform it, etc.
    *) Processes - how do we sequence the activities of users and services to produce some valuable business outcome.
    (of course there are also some other fundemental elements such as users, events and rules that are needed too).

    In my opinion, any architecture or system design needs to deal with Process/Services/Information (PSI) - of course depending on the type of system one of these may be much more important than the others.

    For instance, procurement systems tend to be process-oriented because they typically focus on streamlining the work of multiple people as part of the buying/selling of goods - something processes are designed to facilitate.

    Another example is decision support systems where information is the key driver (and ad hoc collaboration of multiple people is important for enriching this information) and process might be less important.

    A typical example of a service-oriented system would be an online banking system where the client is mostly interested in the services they can perform (deposits, withdrawals, transfers, automatic payments, etc.) - note this definition of service-oriented is different than what you see in a lot of recent books.

    At the end of the day, every system combines PSI and it is important to determine which one predominates and which ones play a supporting role.

    I contend that any process-oriented system or any information-oriented system ideally should be built on an SOA (not necessarily WS*). This is because services provide both process-oriented systems or any information-oriented systems with a clean abstraction that is independent of the underlying technology layer.

    I contend that the most important aspect of building an SOA is defining the data model (or the information model) for the information that makes up the service interfaces - this is the key to interoperability and information sharing. If you get the data models for the service interface wrong (or they aren’t adaptable), then your SOA is nearly useless. Of course, services that belong to the same business domain will share a data model and services that belong to different business domains will have different data models (and then we have to decide how to translate among the data models when service requests cross business domains).

  4. SOA digest » Information-Oriented Architecture (IOA) said,

    May 31, 2006 at 9:35 am

    […] More info […]

  5. Insights » “Curses! Foiled Again!” said,

    August 17, 2006 at 7:19 pm

    […] The title of the post relates to the similarities of the NetKernel architecture (at least on the surface, I haven’t done a deep dive yet) to what I was trying to explain in the SOA CoP forum a while back that eventually prompted the post on Information-Oriented Architecture back in April. It is also quite close to the internal research that I’ve been doing about what would be the optimal way to deliver an XML messaging system–if that’s what you were trying to do. […]

Leave a Comment