developerWorks: Hello, everyone. This is Michael O'Connell, editor in chief of developerWorks at IBM. And today I have the privilege of speaking with Steve Mills. Steve, as most of you know, is senior vice president and group executive of IBM Software Group and responsible for directing the development, as well as the marketing and sales and support of IBM's software portfolio. Steve, thanks very much for joining us today.

Mills: Thanks.

developerWorks: I was hoping to ask you about, as the leader of IBM software, ask you about what new do you see as the most noteworthy trends that would be of interest to software developers and IT professionals?

Mills: Well, I think there are a couple of areas that are important for our customers. And let me approach my answer from the perspective of the customers — not so much vendor/partners who are building commercial products for resale.

I think the customers are at a point now where they need to think about looking at their development processes, tools, and techniques, and reach some conclusions on changing some of the historical styles and approaches that they've followed in years past. Frankly, I think one of the biggest challenges customers have around the development of applications is that they far too often over-scope their projects. My view is that you're better off in an iterative approach — time boxing the effort, minimizing team size and recognizing that the best software products or the best software implementations are created over a period of time through iterative approaches that keep refining the underlying functionality, scalability, usability.

Getting it right the first time is literally impossible. Getting it right, getting it better over time, is the more practical approach. And far too many of our clients are stuck on traditional techniques — long projects that often result in dissatisfied end users that, even after they listed out all their requirements, still didn't really feel they got exactly what they wanted. And it's very much tied up in frankly the challenges of human communication. So that by way of change in approach for our customers is one of the critical things that I'm talking to many clients to around the world. The other thing is building our applications for shared-execution environments. You know, the phenomena of client/server led to a highly fragmented development model. In most businesses, developers became comfortable with the idea of building on the same platform they were going to deploy. The net result was the applications were not well suited to being deployed on shared platforms using partitioning, hypervisor, advanced task-management techniques that are available but require some greater thought and planning around "How are you going to build your applications to take advantage of the efficiency of shared operations environments?"

developerWorks: I know that one big focus that ties into the iterative development is the Agile processes that IBM has been focused on. And also I believe that's a big part of what Jazz.net is about. And I don't know if you wanted to share more about those initiatives.

Mills: Well, we got into iterative development techniques around 20 years ago. The industry of late has grabbed on to this notion of Agile. I don't view it as being anything different than many of the techniques and approaches that we've been driving our software business around now for quite a long time. I think the best products are driven with a high degree of user-centric design and focus. You get it right through your tight connection to users, establishing effective use cases, verifying and re-verifying, spending more time on design, setting teams up for an iterative technique, using various team-based development practices and cross-team checking and testing activities in order to bring a higher quality to the product that's delivered ... and, really engage the team fully. In other words, avoid classical separation of duties within development teams that often don't result in delivering the best possible product.

So many of these things which we've been doing for a long time now have been scooped up and codified around Agile. And frankly, over many, many decades there have been many of these types of techniques that have been brought into the marketplace, given labels and so on. What we try to do is capture the best of everything. You know, there's 50 years of good ideas out there, and the challenge is to capture the best of that 50 years of experience and put it to use to deliver better products for our customers.

developerWorks: I know you've been dealing with software in IBM not for 50 years, obviously, but for quite a while. I'm wondering, over the many years, what lessons you have learned that you might want to share with IBM clients and customers who are often in and of themselves software organizations?

Mills: Well, I'm a big believer in time boxed-based approaches to development. I think small team is always better than large team. But there are many products or projects that demand larger-size teams, and the challenge for those managing those teams is how do they organize them and structure them around small-team approaches and techniques while at the same time having the necessary process and coordination points to deliver the final, fully assembled product?

Our success as a software development organization — our speed, our agility, our efficiency, you know — has been driven by maximizing small team techniques, iterative development, time boxing, and a maniacal focus on reuse. I often lecture the teams that the best code is the code you don't write — that we have an enormous library of code within the IBM company. Many of the things that we deliver for commercial use embody elements that have already been developed, tested, are reliable, extensible, repairable. Why go off and start from scratch? And as the IBM development teams know, we practice reuse with a vengeance. And it's resulted in consistent double-digit compound growth and overall development efficiency within our organization.

So the same ideas and techniques can be applied for our commercial clients. It's very much a part of what we try to help them with as we help them with SOA, componentization, the encapsulation of pre-existing software and routines. Now, there's no reason not to keep using the software you have if it's effective, understandable, readable, extensible. And much of what customers have today within some boundary conditions fall into that category and can be used and extended. So why throw it away and build again? Get on the strategy of componentization and reuse because it will optimize long-term efficiency and effectiveness of your IT operation.

In addition, I think we've worked very hard at collaboration, collaborative techniques. We go back more than 20 years, we had, I think, too much isolation across our laboratories today. The more than 80 locations in which we do commercial software development are engaged in a highly collaborative set of processes. They share code, share ideas, they share designs, they work together. Many of our products are, in fact, developed across a dozen different locations. Those teams have to have process technique and, frankly, a belief and confidence in each other to realize the benefits of that type of global collaborative approach to building software.

That's something that we're well out in front of not just other commercial companies but obviously our clients. It's a topic that they often struggle with, and we can bring a lot of knowledge and value around the processes and techniques and management structures essential to delivering software that's developed in multiple locations simultaneously.

developerWorks: Yes. I suppose there's not too many companies that have more folks on their development team than IBM does. Do you know, I guess, we're around 25,000?

Mills: Well, no. In fact, the total IBM software development community for commercial products is about 33,000 people. That's inclusive of all of the programmers in STG, as well as the programming communities within IBM Research that are involved with building software in conjunction with the laboratories. Software Group is about 25,000, but when you take the rest of the community, and I'm not counting IBM Global Services, which would obviously add many, many tens of thousands more to the number. But, we're 33,000 — 33,000 makes us the largest business software development company in the world.

developerWorks: And I can't imagine anybody's more distributed across the globe than we are, either.

Mills: And nobody comes close to the number of locations in the number of countries — not even remotely close to that.

developerWorks: And I understand that part of the reason that we're able to come out with products like Jazz and focus so effectively on the collaboration challenge is because we've been dealing with it ourselves so often and for such a long time.

Mills: That's a problem that we understand. You know, the overall Jazz initiative and now the delivery of Team Concert, the things that we've done around the Rational® tool set from a consistency standpoint. You know, getting everything on to Eclipse, reaching out from the Rational team to the Lotus® team to look at how collaborative social software can be incorporated into these environments. We live this every day, and we're constantly working on ways in which we can improve collaborative development on a global scale, and obviously avoid the disadvantage of having to put everybody together in the same place.

You think of 33,000 people developing software for commercial delivery. You can't conceive of putting all those people in one spot, and frankly, there are great skills everywhere in the world. The diversity of our software development locations actually gives us significant benefit in collecting better insight into what customers around the world are looking for. And our labs, through various outreach programs and processes that we have, are an integral part of supporting the deployment and success of customers with our software in their locations.

developerWorks: As an example from the standpoint of the diversity, our customers are diverse, too. And I understand from a developerWorks standpoint our traffic — the majority of our visitors — come from outside North America. So even though we're based here primarily, and we do have those global sites, it's just another example of how the customers, the clients, are distributed and diverse, too. So, one more reason you want to maintain that diverse perspective.

Mills: Absolutely.

developerWorks: One other thing that I'm wondering about, if it would maybe not quite qualify as a lesson learned, but I know Danny Sabbah has been emphasizing to the Rational team about the importance not just of delivering features with the new products, but also focusing really strongly on value and delivering value. I'm wondering if that ties in at all to any of the lessons you might want to share with the IT professionals.

Mills: Well, many years ago we embraced this idea of user-centered design, you know, which has both science and art associated with it, to be sure. Value is something that each and every customer experiences based upon the goals and objectives that they've set for their business. Whether the tools match existing skills, whether they are intuitive to use or require extensive training, whether they can be applied easily to the nature of the particular project or programming challenge the customer is taking on.

And obviously, tools is a plural word, and so there are multiple tools that make up a life cycle-based development process from the business analysis side through composition into low-level modeling, the generation of low-level code structures, the ability to reach into your library or repository, pull out componentry, incorporate it into the designs ... move things into test, create your use cases and your test scenarios as you're doing your designs so that you can not only speed up the test process but know that you're testing the right things .... And obviously, you get into then the build processes, deployment, and long-term life-cycle management around the technology.

So the customer is going to judge value based upon where they are in their maturity cycle, what the skills and knowledge are of the people they have in their organization. You know, clearly we're building tools that are targeted at enterprise-class applications for the most part. And so therefore, there's a characteristic of those tools that are capable of producing very robust, very scalable transactional code structures. That does require some amount of customer training for them to build the skills necessary to use the technology.

At the same time, we need to keep revising what we're doing in the context of the experience we have in working with them, keep coming back to fundamental user-centered design techniques to keep refining the intuitiveness of the environment that we're delivering. You know, and Danny is focused on, he and I have been focused for many years on, it is a collection of tools, and those tools add up to an environment. And that environment has to be as easy to use as possible for the customers if we both want to be successful from an IBM business sense. And obviously from their perspective, the more intuitive the tooling is the more value they're going to get because their time to value has improved. The relative ease with which the programmers can leverage the tools and deliver effective executables is the critical factor by which we have to judge the effectiveness of what we're developing.

We might take great pride in aspects of scale or feature/function, but only if the most highly trained, you know, best of the best people can use the tools, that's a market-limiting approach to tool design.

developerWorks: One of the challenges with software in general is that you can get lost a little bit in some of the feature/function issues and lose sight of that value. So it's great to hear your perspective on that.

Mills: Yes, and customers do want the features. So it's not as if we're making the products over featured in the context of the various things that customers need to do with their tools, you know, but how you present those features. It's a little bit of, I often use the analogy of, you know, an airplane analogy: The cockpit of an airliner is unbelievably complex, but what's been done through the whole use of glass cockpit techniques and heads-up displays and things of this nature is that you've simplified the fundamentals, allowed the pilot to effectively control and fly the airplane without having to stare at gauges by the dozens.

developerWorks: Right.

Mills: And it's that approach to how do you nest various features? How do you make them readily accessible? But at the same time not clutter up the development experience in such a way that the programmer feels that they're following a very convoluted path in order to get their particular task done.

developerWorks: And the stuff that they need the most is front and center.

Mills: Absolutely. Right.

developerWorks: One other thing that came up at the recent Rational conferences, and have come up in the past, too, is continuing growth of importance placed upon software and on software development teams and IT professionals in general. And Grady Booch has made a great point about that over several years now. And I think from IBM's perspective, the importance of software has grown as well. I'm wondering if you could talk a bit about the importance of software and increasing importance as a key ingredient — or the key ingredient — of the computing landscape and how that's happening in IBM.

Mills: Well, you know, hardware is what the computer is and software is what the computer does. And that's the beauty of programmable computing: It's not fixed function; it's variable. So it's adaptive. Adaptability increases value.

And as we've watched information technology progress over the course of many decades, obviously the relative contribution of software to delivering customer value has been on the rise as software's become more sophisticated, more functionally rich, more diverse. All those things contribute to software's relative value. That's not to diminish the importance of the underlying hardware. There isn't anything we produce that, it's going to work without hardware. And the better the hardware, the faster, the more efficient, the more capable, obviously the more possibilities there are for creating information technology systems, compute environments that are even more flexible, more adaptive, more responsive, more real-time in terms of what the customers are looking for.

And the other dimension that's at play here, and it touches the services side of our business and of the industry at large, is the fact that I believe given economics, labor costs, time to value, there's an increasing push on the part of services companies toward basing their practices around commercial off-the-shelf technology and reusable assets. The advancement of standards, the emergence of consistent architectural structures, things that we've seen evolve out of basic library functions, class libraries, Java™ [technology], Java componentry, scripting, Web services, mashups, all these things that have been evolving over a long period of time are providing the opportunity for mass customization around reusable components. It doesn't diminish the value that service practitioners provide. They still need the knowledge of how to combine and recombine. But the time to value to the customer increases because the service practice becomes more asset-based, rather than labor-based. And that's essential. I mean, it's sort of a post-Industrial Revolution phenomenon that everything in our world in order to become more accessible and deliver more value needs to be asset-based, repeatable — not labor-based.

And software is evolving in such a way as to become more adaptable to these types of asset-driven implementation approaches. It obviously touches on what we tell our customers to do in terms of creating reusable component libraries. That's what we're doing inside of IBM as far as Global Services initiatives, to be asset-driven, which improves Global Services' margins, repeatability, quality and speed. And obviously, the rest of the industry recognizes this same thing. And this is a fundamental shift that's been going on for quite some time. But the technologies, the bandwidth, system performance, is making this more accessible, easier to do. And it's having a profound effect upon the implementation of information technology. And clearly, the software marketplace is shifting to a more asset-driven approach.

developerWorks: You touched on a few things, and adaptable, and reusable, and adoption of open standards. One of the things developerWorks focuses on as well is on those open standards. And I'm wondering if you could, for the folks who maybe haven't fully appreciated, what is the underpinning value that's so imperative in terms of the open-standards adoption as we proceed with IBM, as well as what IBM customers do or clients do.

Mills: Well, you think of, the fundamental objective of standards is to make it easier for things to fit together. And thereby, you can combine and recombine them in different ways. The outcome will be consistent and predictable. It opens up freedom of choice. It provides longevity to code assets that they can be plugged and replugged in different ways. Our customers are dealing every day with the cumulative effect of all the programs that they've either written or bought, which for large businesses can be well in excess of 100,000 programs within their environment. There are hundreds of millions if not billions of programs running in the world today. That's an almost uncountable number. The investment in that software is measured in the many trillions of dollars. It probably pushes $20 trillion of cumulative operational IT expressed in terms of the replacement value of all the software running in the world today. You can't rebuild that. You have to use what you have. And standards, standard interfaces, standard APIs, easily readable interface structures extend the useful life and the value of all that software.

And so it's critically important, if we want the information technology industry to grow, we need to reduce the obstacles to growth. And at this point, integration of everything that's out there is in fact one of those obstacles to growth. It chews up a lot of customer budget, integrating what they have. And the more standardized these interfaces and structures are the easier it is to leverage, extend, add on and continue on this path of leveraging the infrastructure that's there.

developerWorks: One other more recent phenomenon, perhaps, is the focus on community. And whether it's Web 2.0 technologies or collaborative efforts — you talked about collaboration before — I'm wondering if you could talk more about how community contributes to successful software development.

Mills: Well, I think we see this in a whole variety of scenarios. So, I talked earlier about our approach to developing software in a highly diverse global fashion. It's required that we create inside of IBM community structures. In fact, we are quite prolific in our use of social-networking technology — the connections technology that we deliver to the marketplace today are essentially the productization of things we've been working on inside of IBM for the last decade and have been using for various types of community-based collaborative approaches.

There are a few thousand communities in IBM today. There are half a million Dogear documents that are available out there. We have expertise location capability — lots of community tools that people have put to use. And it's helped link the technical community inside of IBM and make it more cohesive.

I like to use the expression virtual genius, since the qualification for genius is a rare thing. How do you enhance your knowledge? How do you enhance your ability to deliver knowledge to your client? Well, if I can collaborate with other smart people cumulatively, you know, we're a virtual genius. We embody the knowledge of many, the knowledge of the community, the wisdom of the community. And I can capture that easily, and I can express it to my client. I can put the experience and background of others to use. I can do things faster and more effectively because of this community linkage. It's a very, very powerful model of execution and of delivering greater value with speed.

I think we can point out other examples. Obviously, we're doing things around community source within IBM. We participate in open source community projects. There is no company more prolific than IBM in its participation in community source-based initiatives. And that community source has provided an acceleration of IT adoption, an acceleration of standards in the industry.

Now there are also, I think, some great examples, you know, of how disparate groups of people have come together and worked on innovative ideas through these community linkage techniques. New ideas, new brainstorms, new things emerge from that. developerWorks is, as an IBM offering, program or offering, is really designed to tap into community interests and community behavior, as I think many people know. developerWorks has a lot of things on it, in it, that go beyond the IBM portfolio. Clearly, we're focused on supporting people around our products and capabilities, but we're active participants in a whole variety of community-based activity, open source initiatives and tools. And developerWorks as a destination for programmers who are not just looking for things IBM but things of interest to them around community-based open source initiatives.

developerWorks: And in the realm of the product space we do have, for example, [Marybeth Raymond] from Lotus, soliciting input on features and functions for their products. And then we're soliciting requests for enhancements for the Rational products. But we're also trying to help everybody with the open technologies, whether it's Linux® or other open source or XML — all sorts of things. So as you point out, it's a broader thing than products. But we do have an extension beyond just content of trying to engage with and get community input. And I think that ties into the model that Jazz has adopted insofar as trying to have the community help shape the development efforts.

Mills: Absolutely. You know, we're more than a decade into these types of techniques within IBM. What we're doing today is an outgrowth of ideas that gestated during the '90s and have led to the portfolio we have today, which is not only more diverse in terms of the range of products that we offer but the incorporation of open source, shared code, community involvement, the solicitation of market input in the evolution of our technologies, is today enhanced quite dramatically by our approach to community-based techniques.

developerWorks: One thing that we've mentioned a few times is Jazz. I'm curious to what degree you see that IBM Software Group developers adopting that. And I don't know if that's a mandate, or to what degree that's going to take time. I'm sure there's different reasons that some folks may adopt it more quickly than others.

Mills: Well, yes, Jazz has become the umbrella for a set of functional capabilities within our portfolio, the tools. Obviously, we have the IBMers on the IBM tool set. And the evolution of the tools that they use is going to continue down that path. We do provide some choices for development teams in some areas, but core infrastructure, getting everybody on to a Team Concert infrastructure, is an important aspect of ensuring that we can do worldwide collaborative development efficiently and effectively, and share code efficiently and effectively. So the entire IBM software community is moving down this path toward being fully enabled around the Rational tool set, the Jazz initiative being just one aspect of what we're doing.

developerWorks: One other question for you, Steve: I'm wondering how much priority from a strategic standpoint IBM is placing or should be placing on future customers or potential customers vs. priority on existing customers and how you balance that.

Mills: Well, you can never quite balance it. You love the customers you have, and you're anxious to get more customers. And we will always have the challenge of our existing customers requesting a lot of us. They buy from IBM because they expect a lot of us. They get a lot from us. And those relationships are important. They ground our business. It's one of the characteristics of IBM that differentiates us from many other companies that don't take as much interest in ensuring customer success with the technology.

Now, having said that, to grow our company, we also need more customers. The IBM company touches a lot of businesses, but we'd like to touch more and we'd like to do more with more businesses. That's one of the never-ending challenges we're going to face, is spreading our resources across those that are working with us closely today and introducing more customers to the capability that we have to offer.

developerWorks: Well, on behalf of the developerWorks community, I wanted to say thanks again, Steve, for taking time to speak and answer some of the questions we had for you. I wish you the best going forward in 2008 and beyond. Thanks again.

Mills: Good. Thank you.

developerWorks: developerWorks' editor in chief, Michael O'Connell, interviewing Steve Mills, the head of IBM Software Group. This has been a developerWorks podcast. Thanks for listening.

Resources

• Rational Team Concert on developerWorks
  
  
• "Developing extensible applications with IBM Rational Team Concert and the Jazz platform: Part 1"
  
  
• Scott Hebner video: Rational unveils Jazz.net and first Jazz-based product in open beta
  
  
• Podcast blog
  
  

About the author

Michael O'Connell is the founding Editor-in-chief and editorial director of IBM's developerWorks site, which launched in 1999. Before joining developerWorks, he served as founding Editor-in-chief of IDG's JavaWorld and a founding editor of SunWorld Online -- two of the industry's first successful Web-based technology magazines. He's been a computer journalist since 1991.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments