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).
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?
- how you invoke it, and
- 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.
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.