It’s been three years since IBM acquired software development company Rational Software for US$2.1 billion, later releasing a new software development environment, the IBM Rational Software Development Platform. Roger Oberg, responsible for IBM’s Rational strategy as vice-president of marketing and strategy, made his first visit to Canada in his new role recently and he spoke with ComputerWorld Canada senior writer Jeff Jedras about the changing world of software development.
What are some of the major trends you’re observing currently around software development?
There’s an evolving need for governance in the business process of development. It’s also a new idea to some that development needs to be treated as a business process, just like any other business process. Historically, I think it’s been more of an ad hoc effort. Governance isn’t specific to any development tool one might use. It has a lot more to do with the clarity of roles, responsibilities and decision-making. (Development is) increasingly distributed, and that brings challenges around who is responsible for what. With service oriented architectures, the same kinds of issues arise. If you’re creating services to be reused in your organization, who makes decisions about how the service performs if it’s going to be used in another context? It calls out for governance, and a high clarity around who does what, who is responsible for what, who pays for what. [There are also] regulatory compliance issues, which have really exploded in the last five to 10 years. These trends really cry out for effective governance practices, and we need to deliver a development platform that meets these evolving needs.
If the market’s needs are evolving, do you have the tools developers need to meet these evolving governance challenges?
I think we’ve got more than most, but we still have work to do ourselves in making it easier to do these things. As an example, we could make it much easier for a financial services organization to document its compliance if we created templates in our Rational Portfolio Management product that gave them an out-of-box view into the data they need to demonstrate regulatory compliance. We’ve got more work to do, and that’s one of the reasons we’re meeting with our teams around the world, to encourage these kinds of improvements to our portfolio.
What do you mean by approaching development as a business process, what would change in the development process?
If you consider all these things as interconnected then you wouldn’t have a set of requirements defined in a document and then not be able to validate in some reasonable way whether those requirements were reasonably tested out. If you think of it as a business process you want some ability to trace the requirements you need to meet through the test case that validated it. That’s the kind of change in thinking that occurs when you think of it as a business process. Historically in development, we’ve siloed activities, with dedicated teams for QA, architecture, sometimes business…defining requirements, and today each part of the process just throws it over the wall. When you think of it as a horizontal business process it changes the way people are obligated to work together and changes what the products that support you do. In lots of little ways it changes the way you automate what people do.
These all seem like sensible ideas, so why isn’t this already happening?
I think historically we’ve had a higher tolerance for software that is late or wasn’t of the highest quality, particularly if it didn’t kill anyone. The people that have really been heading in this direction are those in highly sensitive fields like medical devices and aerospace software. But now, when businesses have a vested interest in distributing work to the subcontractors that are best able to do it, that forces you to pay attention to the processes more closely, and to who is doing what. We knew it was a good idea, we knew it was good medicine, but now it’s a business imperative.
How much of a factor has the difficulty around governance and assigning responsibility in a distributed or service oriented architecture environment been in hampering the wider adoption of SOA, particularly in the public sector?
The governance issues around SOA are pretty fundamental because SOA really introduces reusability at a scale we haven’t had before, and that brings a lot of challenges to the way you do things. I think the biggest issues around adopting SOA are to get these business issues defined, clarity of decision-making, roles and responsibilities; these are the things companies are floundering on.
What’s the answer then, is it clearly defining these things on paper at the outset, or is there an IT answer here?
We’ve thought pretty hard about it, and we think there’s really four governance activities that, depending on where your point of pain is, comprise a lifecycle you ought to adopt and think of governance issues in the context of. They’re planning activities, defining activities, enabling activities, and measurement activities. There’s a lot more to it, but we’ve got a lot more information and advice (in each area).