Entries from October 2007 ↓

I recently saw a great presentation by Becky Wanta about her experiences as the CTO at PepsiCo. Becky talked about some of the “key capabilities” that needed to be developed in the PepsiCo IT organization. One of these capabilities – which I think is often overlooked – is Design for Change.

Capacity to change is a fundamental aspect of Enterprise Architecture. Many of the failings of Enterprise IT such as lack of agility (rigidity), misalignment with the business, and high cost of ownership have to do with an inability to change, and from this perspective I think many people miss the point of Enterprise Integration. The primary purpose of Enterprise Integration Architecture is to support change.

Enterprise Integration is not about getting data from one place to another…if that were the case, then point-to-point integration using scripts would be sufficient. Enterprise Integration must provide a platform which allows the IT infrastructure (the applications, services and processes) to change in line with the needs of the business. Design for Change is a fundamental aspect of SOA, but it is not something that happens automatically.

So how do we design for change? Here are a few best practices:

• Change must be built into the culture of the IT organization. Too often, people build solutions for release 1.0 and without thought for how those solutions will mature, evolve and become obsolete. All solutions have a natural lifecycle that must be figured into the design, implementation, verification and support of the solution.
• Change processes must be a natural part of the system development lifecycle and should be automated as much as possible. Many organizations struggle with regression testing or integration testing because they treat these processes as one-off activities that are part of a development project – rather than planning for them to occur as “business as usual”.
• Different parts of the infrastructure will change over different timescales. Loose-coupling and location transparency are desirable architectural properties because they enable different parts of system to change with minimal disruption to the system as a whole.

And taking a “change-centric” approach to Enterprise Integration can greatly smooth IT transformation – the process of making radical changes to an IT infrastructure, often accompanied by significant business disruption. Some of the more successful IT transformation initiatives I have seen were successful because they regarded Integration as an enabler of the transformation, rather than just another component. Hence leading the transformation effort with a significant investment in the right Integration Architecture (designed for change) allowed transformation activities to extend over significant periods without significant disruption to the business.

The Gartner hype cycle for Application Infrastructure Middleware, Platforms and Architecture 2007 says that SOA is sliding into the trough of disillusionment. That’s great news because it means the meaningless hype is substantially behind us and we can look forward to climbing the slope of enlightenment.

The recent rise and fall in hype around SOA takes me back to the late eighties when there was similar hype around object-oriented technologies. OO had a similar “business case” to SOA in that it was supposed to magically provide faster and lower cost development through re-use of OO libraries and assets. “Agile” is the word we would use now…but I don’t recall it being used at that time.

At the same time as we had all the OO hype, there was a lot of confusion about OO languages (at the time there was really on SmallTalk and C++ on most peoples radar), about OO concepts – what is an object, what are the right object sizes, structures, relationships? And there were many disasters involving software developers trying to shrug off procedural feet of clay and launch into the new OO paradigm. Lack of standards were a big problem too…C++ compilers and libraries were not interoperable.

And the promises of re-use never really got of the ground without substantial amounts of “Governance”.

So what happened to the OO hype? It magically disappeared into the background. Noone ever talks about OO now, it is just a given. But there are some interesting events that happened along the way.

A new OO-based languge (Java) came along to effectively “democratise” the concepts. People no longer had to struggle with the complexities of C++ in order to use OO. Java also came with a rich set of class libraries that gave you an awful lot of power out of the box – previously only available through buying expensive commercial class libraries. I think it was this set of standard classes that engendered a whole raft of re-use.

Another important milestone for OO was the emergence of design patterns as a way of communicating and recording OO best practices. And more recently we have some pretty good innovations to support agile development pactices – things like continuous build and integration which automate a lot of the grunt-work involved in the software development lifecycle.

So what will the SOA landscape look like in 10 years time when its a “no-brainer” and everybody is operating in a services-world? Presumably SOA design patterns will have emerged to address the confusion around service concepts – what is the right size, structure, relationships between services?

What will be the platform of choice for developing, producing and consuming services?