InfoWorld's next SOA Executive Forum will be November 7 and 8 in New York, and I've been sketching out proposed talking points for the sessions I'm involved in. As always, I'm looking for additional perspectives, so fire away if you have them. You can use the email link on this blog, and/or if you'd like to use your own blog for this purpose, please do. In the latter case you might want to ping me also, though I'm pretty certain my sensors will catch it if you merely link to this entry. Come to think of it, that's an interesting experiment: exactly how reliable is that mechanism? Anyway, here's what I've got so far for Day 1.
Following the keynotes, we'll have two general sessions on the theme of agility -- first from the perspective of business, and then from the perspective of IT. Here are some of the aspects of agile IT infrastructure I'd like to propose for discussion.
Reuse and composition. We've always wanted to be able to compose applications from existing parts. How and why is SOA enabling your IT infrastructure to realize that ambition? In what ways isn't it?
Smoother integration of vendor-supplied components. SOA components, such as repositories and security gateways, are nowadays themselves service-oriented, and vendors say that as a result it's easier than ever to select best-of-breed products and use them together. Let's explore that.
Migrating to policy-driven intermediation. Extreme agility becomes possible when policies around security, service-level agreements, and compliance auditing are lifted out of code and placed into declarative policies enforced by intermediaries. But today, much of that policy is woven into your applications. How do you externalize it?
Consuming services. Your SOA infrastructure isn't only a producer of services, it's also a consumer of them. These consumed services confer agility, but also entail risk and hassle. How do you maximize the benefits and minimize the drawbacks?
From James Taylor: Rules engines:
I thought it might be interesting to discuss SOA and business rules at your forthcoming events. Some discussion of why is here - http://edmblog.fairisaac.com/weblog/soa/index.html - but essentially business rules are ideal for building business logic services and for orchestrating services.
From panelist Carl Ververs: Organizational issues:
We should not forget to spend some time discussing the organizational issues that can make or break SOA payout. Inter-departmental strife and turf wars, not to mention the conflicts of priorities between service provider and consumer can be formidable obstacles to getting standards and a central management infrastructure established. This then will diminish the reusability and agility of SOA.
Hot topics today include what exactly constitutes metadata, where to store it, how to declare policies with it, and how to query it. Here are some topics I'd like to propose for this session.
Prescriptive and descriptive roles. One of the repository's roles is prescriptive -- i.e., to be a mechanism for asserting SOA-related policies. Another role is descriptive -- i.e., a way to keep an inventory of assets. How do various implementations balance these two roles?
Sociological tactics. The landscape is littered with the corpses of failed repository initiatives. How do you avoid becoming roadkill?
Human protocols. Along with technical protocols and standards, like UDDI and XQuery, there are human protocols that govern interaction with the repository. What are the roles and responsibilities, and how do the various actors -- developers, system administrators, business stakeholders -- work together?
Persistence strategies. What kinds of artifacts should be stored in the database? What kind of database is appropriate, and what kinds of structured and semi-structured queries must be supported?
From panelist Miko Matsumura: Repository requirements:
Because there are so many different kinds of repository, the key question then becomes which of the repository features actually matter for SOA builders? How do those features change from design time to run time to change time?
From the perspective of conventional software development, SOA-style development tends to be more closely business-aligned, more decentralized, and more fully governed by contracts and policies. Here are some topics to explore.
Business-layer and IT-layer design. Setting aside the specific tooling -- e.g., whether business analysts and developers can collaborate in a shared graphical environment -- in what ways does SOA design naturally accommodate both business and IT concerns? In what ways doesn't it?
Patterns vs frameworks. Some developers are looking for prescriptive guidance: blueprints, pattern libraries. Others would rather be using frameworks that just embody best practices for, e.g., asynchronous messaging. What role do these two approaches play in SOA?
Procedural coding and declarative policy. SOA brings a slew of standards and protocols. In the realm of security, for example: WS-Security, WS-Trust, WS-SecureConversation, etc. One way to manage this complexity is procedural, relying on ever-smarter tooling. Another way is declarative, relying on smart intermediaries. How do you evaluate these options?
Code repositories and service repositories. To a developer, a repository is a CVS tree that contains code and related artifacts. To a services-oriented architect the word repository may mean a collection of interface definitions and policies, or a mechanism for defining and enforcing policies. What kinds of automated systems and human procedures connect these two kinds of repositories?
Testing and debugging. SOA's compositional style can result in applications that depend on services that distributed across geographies and organizations. How do you test and debug these applications?
From panelist Scott Hanselman: Messages vs objects:
How does SOA design change or break the "classic" OOP design rules from the 80s and 90s? Do the Fowler-esque Domain Modeling Designs still apply? Are we exchanging messages or objects? Are we collaborating over the wire protocol or the in memory object graph? How does this affect interoperability? Does SOA have to have a .NET-centric or Java-centric view? Where is state stored?
From panelist Tim Ewald: RPC vs document:
Another one I'd add is the separation between the high-level architectural discussions of SOA and what the developers see in their tools. For instance, SOA could imply RPC, messaging, or document transfer. You can build all three types of architectures with SOAP and WSDL. You can build all three with WS tools, but some tools prefer one over another. Does SOA imply any one of these or does it matter? And if it does, but your tools don't support that, what do you as the developer do?
From Jeffrey Fredrick: Testing and quality:
1. SOA breaks the traditional model of application testing
2. for the federated services model of SOA to work there will need to be a way to communicate trust at a distance.
wrt 1, consider the traditional approach to testing -- create a little model of the real production system and test against it. how does this work in SOA land? if you are the service consumer, is there a test version of the service you are using available to you or no? and if there is, do they behave enough like the real production version of the service? even worse if you're the service provider! how do you possibly build a model of the world when your service consumers may not exist yet? and what happens when a service consumer suddenly changes their usage profile on you?
wrt 2, this is the follow on from #1. if I'm going to use your service how do I gain trust in what you've done to test and prepare your service for me?
I've written before on my blog about how tests should make an existing code base more valuable, and while I think that is true in all situations I think that will be even more true in the SOA world where you'll really want something like a dashboard from any of your service vendors.
Perhaps SOA will be the driving force that makes the Open Quality idea take off?
From Bob Rhubart: Consolidated repositories:
I hope the solution Jon proposes involves the use of a software asset registry that connects the CVS repository with the services repository, connects both of those to the project portfolio, and maps any and all asset-to-asset and asset-to-project relationships.
I can recommend such a registry, if necessary.
Former URL: http://weblog.infoworld.com/udell/2005/10/20.html#a1325