Policy-based management may help bridge some pitfalls in SOA's evolution

I had a nice chat with Rich Seeley at TechTarget this week on SOA and management, and he produced this story. The major theme of the article is that SOA forces a new kind of management, one that's by necessity highly inclusive and crosses the borders of the emerging loosely coupled services landscape. A standardized fabric approach to SOA management that spans design, development and runtime -- as well as the mixed services lifecycle (wide AND deep) -- remains a goal, but not an easily attainable one for most enterprises and service providers.

Fellow IT software and SOA blogger Joe McKendrick had a post that factored this all into what may be holding SOA back at many organizations.

Not long after I spoke to Rich, I took a briefing with three other vendors that somewhat cheered me up about the topic. First Dan Potter, vp of marketing at WebLayers, re-energized my understanding of the role of policy-based management, and how SOA reshuffles the policy deck to include impacts on governance, registries and repositories, runtimes and processes. The recent IBM Rational Asset Manager announcement adds another major component to what policies may help coordinate, automate and extend.

Potter, who like me is a big fan of New Hampshire lakes right about this time of year, explained that WebLayers has some 1,000 pre-built policies that can be applied to SOA development, useage and extensibility. Nowadays, many organizations rely on peopled review boards and physical documents to admit and govern SOA components and processes. And that's in design time, never mind runtime.

We could call it HOA, Human Oriented Architecture. Such wetware/committee approaches just don't scale well, are hard to repeat, and can not be applied well across the many tentacles of SOA penetration through the enterprise. The fruits of such labors remain largely outside of and separate from the architecture's grinding gears and cogs.

Automating the review of artifacts and applying proven policies via visual interfaces for their use and inclusion, however, marks a significant step to technically managing loosely coupled activities comprehensively. Policy-based approaches -- including wider adoption of WS-Policy -- should become more common for SOA lifecycle management. But like the weather, a lot of people talk about WS-Policy but don't do much about it.

WebLayers also had an announcement this week on its benefits in conjunction with Oracle environments. (Side note: How about those Oracle numbers?)

I also spoke this week with Ryan Martens, founder and CTO of Rally Software. Rally has some products that help development teams attain agile benefits, on the project, program and ALM levels. But what makes Rally relevant to this discussion is the way the products are delivered -- they are predominantly software as a service (SaaS) offerings. And by being SaaS, development in fast iterations is far better managed, tracked, measured, and facilitated.

What's more, Web 2.0/Enterprise 2.0 values can be quickly applied. Keep it allin the systems so the people and process can be better coordinated, leveraged and reused. As you manage your development activities online you can also gather and share as communities online -- both communities of developers but also end users. Create a component or service and run it by a user focus forum as a blog or wiki (Rally prefers hives) before the build. Talk about feedback and iterative improvement.

Damon Poole, CTO at AccuRev, is promoting what he calls Hyper Agile -- a mashup of lean and agile development principles. When I spoke with him this week, I learned his goal is to make agile mainstream. I'd like to see agile also go deeper into how SOA is managed and improved. Indeed, SOA should be a market driver in itself to Hyper Agile.

Get this: SOA could make Hyper Agile imperative for services development, which forces more need to manage and govern services, which then begs use of agile principles in SOA governance, which leads to better while looser coupling to operational demands and performance. And so on. We could see such an adoption virus. Again, we come back to people, process, and technology and how to make them work well together on a recurring and coordinated basis (wide AND deep).

Managing agile development workflow, I believe, has a bearing now on the SOA management discussion. Somewhere, somehow the data, control and shared best practices of a Rally approach, a Hyper Agile mentality, and a policy-based apparatus will coalesce into best practices that no SOA architect should ignore. It will provide significant value to the operators too. Policies may become the lingua franca of how these now disparate IT orbits become aligned and in ongoing collaboration.

Software development as a service elevates that role to more easily relate to policy-based SOA reviews and governance that then relates more to traditional management. The pieces are falling into place. People and process must now provide the mortar that binds refines, and standardizes.

This could become a major productivity boost to IT generally, and begin to knock down the higher ongoing IT costs dilemma that impacts us all. SOA is only as successful as its management.