One of the cool things about my job is I get to talk with a lot of smart people – from both the enterprise IT and vendor communities. On the vendor side, I’ve had the chance to speak with individuals who are providing thought leadership in the (complementary) spaces of service-oriented architecture (SOA), event-driven architecture (EDA) and enterprise integration (enterprise service bus (ESB) solutions).
Invariably, the conversation veers from the products their companies offer, to the bigger business and technology universe. “What problems are businesses trying to solve? What are the business and technology opportunities? How do they
envision the future of information interchange? What will future IT portfolios look like? How service-oriented can we (should we) be? What new business and technology problems/challenges/opportunities will the solutions create?”
While these tangents probably make some of the product marketing folks on the calls (or in the room) nuts, for me (an architect), it’s the most important part of the conversation. I want to know more than the product offering and how it works. I want to understand the overall context, and more specifically, the intent of the creator/steward. You know, the “what were you thinking” question, but in the positive.
This understanding – what I formally refer to as “architectural premise” – helps you align your architectural vision with that of the provider, and it clues you in to the provider’s future innovations and investment. Frank Martinez of Blue Titan in one of these conversations aptly described this concept, as enterprises aren’t just buying products; they are “applying intellectual capital”.
So, what does this “architectural premise” look like, and how can architects find it? As to what, in my recent ESB evaluation framework, I added the following questions to consider on the integration provider’s view of the challenges of integration and the future of services:
When considering architectural premise, think about how your architectural direction (point of view) aligns with that of the integration provider:
- Do they view a future of heterogeneous applications, information, and services?
- Do they view a future of homogenous assets, built around the Web Services specifications?
- Do they have an RPC (verb) view of services? Services provide action, via an operation.
- Do they have a REST (noun) view of services? Services deliver and manage documents.
- Do they emphasize technical mediation challenges over business and data mediation challenges?
- Do they believe the ESB is smart? Or do they believe the smarts are at the endpoints?
- Do they account for a human in integration? Do humans perform actions in an integration scenario? Do humans initiate an integration scenario? Is the human (user interface) a type of integration service?
- How do you view the above?
As for how to find the underlying (and overarching) architectural premise, I’ll certainly be sharing what I learn here (and in my day job), but there are more direct routes, such as the blogs of these folks, and forums such as IT Conversations.
Now for some name dropping, and more importantly, the links to learn what they are thinking: Miko Matsumura of Infravio, Annrai O’Toole of Cape Clear, Michael Terner of KnowNow, Ronan Bradley of PolarLake, Frank Martinez of Blue Titan.
