Thursday, August 14, 2008

Survey says: Aligning IT operations with business goals increases agility, cuts costs

Aligning IT with business goals -- and the benefits that brings to a business -- have long been a recurrent theme of the podcasts and discussions we've done over the last few years. So it's gratifying to see a worldwide study showing that businesses are not only pursuing this strategy, but are reaping significant benefits from it.

A survey of nearly 1,000 IT professionals, from the C-level down to frontline workers, indicates that 27 percent of companies responding are in the process of a business transformation, with another 27 percent having just completed one, and another 30 percent considering changing their processes.

Conducted by the Economist Intelligence Unit, London, and sponsored by Cisco Systems, the survey also revealed that improving IT responsiveness to new business requirements was the top IT objective for 57 percent of the companies. Of the companies that have completed a transformation, 43 percent said that cost savings were the top benefit they realized. Another 40 percent reported smoother, more flexible operations.

While other companies reported different effects, the most astonishing result was that only 2 percent of companies reported no tangible benefit. This would seem to indicate that transforming your business model has a 98 percent probability of success, which is pretty impressive.

One interesting result in the survey was the revelation that companies in India lead the pack when it comes to aligning the operations with business goals:
For example, respondents in India are by far the most likely to have goals associated with interacting with business counterparts. Those goals include implementing new projects based on corporate—not information technology (IT)—objectives, actively seeking opportunities to propose technology-based approaches to improving business practices and gaining more support from senior business managers for things like budgeting, change management and technology adoption.

The willingness among Indian IT groups to “go where the business is going” and take concrete steps to pursue highly collaborative working environments is perhaps one explanation for why Indian respondents were most likely to identify their companies’ organizational structures as “very effective."
The report attributes this to the fact that technology executives in India seem to have greater power in the organization. A higher percentage of Indian chief information officers (CIOs) report directly to the CEO than is typically the case in the U.S., Europe, or the Middle East.

One drawback in many companies is a lack of clear communication of business and IT goals. The survey showed that 49 percent of CIOs saw contributing to business goals as one of their top objectives, but this view was shared by only 30 percent of frontline workers. At the same time, 59 percent of IT architects saw cost cutting as an objective, while only 45 percent of CIOs thought the same thing.

The entire survey report, which isn't very long, is well worth a read for anyone involved in IT, or the business of IT. It is available for download (PDF file) from the EIU site. There is also a Webcast that explains some of the finer points.

Here are the key conclusions and recommendations from the report.
Addressing corporate cultural issues is key to any successful IT transformation project. Senior IT executives must work doggedly to communicate goals, and build bridges up and down the chain of command throughout the organization, both in business strategy sessions and regular meetings with technology employees.

IT transformation is not a cure-all. Changing processes and organizational structures may make IT departments more agile, but will do little good if IT professionals do not adapt their thinking around how better to align their efforts with that of the business on a regular basis.

Walk before you run. Before embarking on a large-scale IT transformation initiative, assess the length of time it will take to complete the effort, as well as the costs, risks and eventual benefit to the business.

Track—and publicize—success. Make sure to assess the return on investment of any IT transformation project. Not only will it strengthen IT’s reputation among business partners, it could help to build momentum for future IT initiatives.
Can't argue with all of that. Of course, it is all clearly easier said than done.

Wednesday, August 13, 2008

Borland's own ‘journey' to Agile forms foundation for new software delivery management solutions

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Sponsor: Borland Software.

Read a full transcript of the discussion.

Borland Software has been in the developer productivity field for decades, but when it came time to build out a new software delivery management suite for application lifecycle management, Agile Development methods became both the means and the ends.

Over the past few years, the development process at Borland shifted dramatically to Agile and Scrum practices, which in turn deeply influenced how the new products were crafted and refined. These shifts fundamentally impacted a set of recent new products. [See product and solution rundowns. See demo and see launch video.]

To learn more about Agile Development and how Borland used the methods to build their own software management products and solutions, I recently spoke with Peter Morowski, the senior vice president of research and development at Borland. He described the journey, the productivity and business outcomes benefits, and the potential pitfalls and errors to avoid. He also wrote a great article on the experience.

As part of the podcast, I asked Peter what surprised him most about this Agile journey at Borland. "The thing that surprised me," he said, "is how powerful it is each morning when everybody gets around the table and actually goes through what they've done, basically saying, "Have I lived up to my commitments? What I am committing to the team today? And then is there anything blocking?"

"Generally speaking," said Morowski, "a lot of developers tend to be quiet and not the most social. What this did is that it just didn't allow the few people who were social to have input on what was going on. This daily stand-up had people, everybody on the team, contributing, and it really changed the relationships in the team. It was just a very, very powerful thing."

Here are some excerpts from the discussion:
Look at the late delivery cycles that traditional waterfall methodologies have brought upon us. Products have been delivered and end up on the shelf. The principles behind Agile right now allow teams to deliver on a much more frequent cycle and also to deliver more focused releases.

What I have observed over my career was the fact that there really existed two worlds. There is what I call the "management plane," and this is a plane of milestones, of phase transitions and a very orderly process and progress through the software development lifecycle.

Underneath it though, in reality, is a world of chaos. It's a world of rework, a world of discovery, in which the engineers, testers and frontline managers live.

What [Agile] is really about is that teams begin to take ownership for delivering the product. What happens is that, by allowing these teams to become self-directed, they own the schedule for delivery.

Hiring is important, regardless of what methodology you use, and I tend to stress that. I do contend there are different kinds of personalities and skill sets you are going to be looking for when you are building Agile teams, and it's important to highlight those.

It's very important that whoever comes onboard in Agile team is collaborative in nature. In traditional software environments, there are two roles that traditionally you may struggle with, and you have to look at them closely. One is the manager. If a manager is a micromanager-type, that's not going to work in an Agile environment.

What happens is that you see some things like traditional breakdowns of roles, where they are looking at what work needs to be finished in a sprint, versus "Well, I am a developer. I don't do testing," or "I am a doc writer, and I can't contribute on requirements," and those types of things. It really builds a team, which makes it a much more efficient use of resources and processes, and you end up with better results than you do in a traditional methodology.

When Borland first started developing in Agile, we had multiple locations, and each site was, in essence, developing its own culture around Agile. What I found was that we were getting into discussions about whose Agile was more pure and things like that, and so I decided to develop a Borland Agile culture.

As we've grown, and our projects are getting more complex, the fact that we evolve from site-to-site based on the same process and the same terminology has allowed us to now choose more complex Agile techniques like Scrum of Scrums or work across organizations, and have a common vocabulary, and that kind of common way of working.

One thing we clearly did was, once that we saw the benefits of doing this, we had a lot of executive sponsorship around this. I made it one of the goals for the year to expand our use of Agile within the organization, so that teams knew it was safe to go ahead and begin to look at it. In addition, because we had a reference implementation of it, it also gave teams a starting point to begin their experimentation. We also paid for our teams to undergo training and those types of things. We created an environment that encouraged transformation.
Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Sponsor: Borland Software.

Read a full transcript of the discussion.

Tuesday, August 12, 2008

Discussion features insights into using RESTful services plus a cool iPhone app

For a quick update on creating RESTful services, check out IONA Technologies' webinar moderated by yours truly. The recent webinar was part of IONA's "Open Source in the Enterprise" series, and is archived on their Website. (Note: free registration required.)

Included in the discussion is my introduction on how to increase value payback, followed by a presentation from Adrian Trenaman, distinguished IONA consultant, on creating RESTful services using FUSE.

Finally, Roland Tritsch, IONA director of services in EMEA, demos a really cool method for accessing RESTful FUSE services from the iPhone. [Disclosure: IONA is a sponsor of BriefingsDirect podcasts.]

IONA has been making the news recently, especially the announcement just a few weeks ago that it was being acquired by Progress Software. A few weeks earlier, IONA released a set of enhancements to Artix Data Services designed to reduce risk exposure and operational costs.

Just over a year ago, I produced a podcast with Dan Kulp, principal engineer at IONA, and Debbie Moynihan, director of open source programs at IONA, in which we discussed the incubation Apache CXF project.

Monday, August 11, 2008

WSO2 data services provide catalyst for SOA, set stage for cloud-based data hosting models

Listen to the podcast. Download the podcast. Listen on iTunes/iPod. Sponsor: WSO2.

Read a full transcript of the discussion.

In the past, data was structured, secure and tightly controlled. The bad news is that the data was limited by the firewall of personnel, technologies, and process rigidity. Today, however, the demand is for just-in-time and inclusive data, moving away from a monolithic data system mentality to multiple sources of data that provide real-time inferences on consumers, activities, events, and transactions.

The move is in the ownership of data value to the very people who really need it, who help define its analysis, and who can best use it for business and consumption advantage. Analysis and productivity values rule the future of data as services.

But how to jibe the best of the old with the needs of the new? How to use data services as onramps to SOA? How to bring data together for federated analysis? And how to use the power of open source licenses and community to encourage the further federation of data as standardized consumable services?

To answer these questions and to learn more about the quickly evolving data services landscape, I recently spoke with Paul Fremantle, the chief technology officer at WSO2; Brad Svee, the IT manager of development at travel management leader Concur Technologies; and James Governor, a principal analyst and founder at RedMonk.

Here are some excerpts from the resulting podcast:
The live, connected world needs to be managed properly and it's very, very difficult to build that as a single monolithic system. ... The [new] model is of keeping the data where it belongs and yet making it available to the rest of the world.

Our data is trapped in these silos, where each department owns the data and there is a manual paper process to request a report. Requesting a customer report takes a long time, and what we have been able to do is try to expose that data through Web services using mashup type UI technology and data services to keep the data in the place that it belongs, without having a flat file flying between FTP servers, as you talked about, and start to show people data that they haven't seen before in an instant, consumable way.

It seems clear that the status quo is not sustainable. There is inherent risk in the current system, and simply retrofitting existing data and turning it on as a service is not sufficient.

We have been trying to free up our data, as well as rethink the way all our current systems are integrated. We are growing fairly rapidly and as we expand globally it is becoming more and more difficult to expose that data to the teams across the globe. So we have to jump in and rethink the complete architecture of our internal systems.

The browser becomes the ubiquitous consumption point for this data, and we are able to mash up the data, providing a view into several different systems. Before, that was not possible, and the additional piece of moving the file between financial system, for example, we are able to not have to pull files, but actually use Web services to send only the data that has changed, as opposed to a complete dump of the data, which really decreases our network bandwidth usage.

[Yet] most of the data that we are dealing with is fairly sensitive, and therefore almost all of it has a need for at least per-user access basis, as well as, when we are transporting data, we will have to make sure that it's encrypted or at least digitally signed.

What we have built is what we call WSO2 Data Services, which is a component of our application server. The WSO2 Data Services component allows you to take any data source that is accessible through JDBC, MySQL databases, Oracle databases, or DB2, but, in addition, we also have support for Excel, CSV files, and various other formats and very simply expose it as XML.

Now this isn't just exposed to, for example, Web Services. In fact, it can also be exposed by REST interfaces. It can be exposed through XML over HTTP, can even be exposed as JSON. JavaScript Object Notation (JSON) makes it very easy to build Ajax interfaces. It can also support it over JMS, and messaging system.

So the fundamental idea here is that the database can be exposed through a simple mapping file into multiple formats and multiple different protocols, without having to write new code or without having to build new systems to do that.

What we're really replacing is ... where you might take your database and build an object relational map and then you use multiple different programming toolkits -- one Web services toolkit, one REST toolkit, one JMS toolkit -- to then expose those objects. We take all that pain away, and say, "All you have to do is a single definition of what your data looks like in a very simple way, and then we can expose that to the rest of the world through multiple formats."

I think that open source is absolutely vital to making this work, because fundamentally what we're talking about is breaking down the barriers between different systems. As you say, every time you're pushing the proprietary software solution that isn't based on open standards, doesn't have open APIs, and doesn't have the ability to improve it and contribute back, you're putting in another barrier.

Everyone has woken up to this idea of collaboration through Web 2.0 websites, whether through Flickr or FaceParty or whatever. What the rest of the world is waking up to is what open-source developers have been discovering over the last five to 10 years. Open source is Web 2.0 for developers.

Open source drives this market of components, and it's exactly the same thing that happened in the PC market. As soon as there was an open buy off that wasn't owned by a single company, the world opened up to people being able to make those components, work in peace and harmony, and compete on a level playing field. That's exactly where the open-source market is today.

That's exactly the sweet part in my opinion. I can shake and bake, I can code up a bunch of stuff, I can prototype stuff rapidly, and then my boss can sleep well at night, when he knows that he can also buy some support, in case whatever I cook up doesn't quite come out of the oven. I see there's a kind of new model in open source that I think is going to be successful because of that.
Listen to the podcast. Download the podcast. Listen on iTunes/iPod. Sponsor: WSO2.

Read a full transcript of the discussion.