IT agility

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?

The evolving role of the repository

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?

Developer's view of the services infrastructure

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?