developerWorks: This is developerWorks interviews. I'm Scott Laningham. Our guest this time is Hayden Lindsey, IBM® Rational® vice president for Enterprise Tools and Compilers. Hayden, welcome to the podcast.

Lindsey: Thanks a lot, Scott.

developerWorks: Now, Hayden, you're here in a broad sense to talk about enterprise modernization. I'd assume that that term can mean different things in different situations. So when you use it, are you referring to sort of a major transformation of IT within an enterprise? You know, sort of a rethinking of the current approach employed?

Lindsey: Yes, well, the sort of background on enterprise modernization and the need for it in the first place is that businesses of all sizes are realizing the need to have greater degrees of flexibility in order to remain viable in the markets that they serve. And IT tends to be a key underpinning for most of these businesses. Even your small companies end up using IT. And so while a business may not be primarily in the business of IT, IT is a key underpinning and, therefore, is a first-class, needs to be treated as a first-class, business process in and of itself.

Unfortunately, IT tends to be a bit of an inhibitor in many of these companies when it's just not as flexible as many of these companies would like and, therefore, it's inhibiting the overall business flexibility. And so enterprise modernization is broadly speaking intended to be a conscious and fundamental process for making change to IT to inject more flexibility. And by the way, when we talk about enterprise, we're really referring to the entire IT organization, and we're not just talking about what some people may call "legacy" or the "mainframe" part of the platform. And, therefore, modernization is referring also to many dimensions and is not just about modernizing the applications. That's another misconception people tend to have. It's about other dimensions, such as the organization, the processes the people use, the tools and so forth.

developerWorks: How big is this need, Hayden? I mean, do we have a sense of kind of the state of the enterprise today along the adoption of this kind of a thinking? Where are we at in that? Or maybe even I should be asking, is there such a thing as a typical enterprise? Or is each one so unique that it's kind of silly to think in those terms?

Lindsey: Well, Scott, it's certainly the case that no two companies are identical. But you know, having worked with many clients over the years, we do very much see some fairly common patterns and, of course, that's why we've put together this enterprise modernization set of solutions. For example, most companies that have been in existence for any amount of time have a fairly substantial investment in applications that they view as business-critical. These are the applications that are running the business. And likewise, they have a fairly substantial investment in the IT staff that understands their business that may have built those applications that may be maintaining those applications or extending them. And so you have this critical set of assets and applications , as well as people that are keeping the business running. And so this is certainly typical of most companies out there of any size.

Another common pattern we see is that the IT organization is generally split in two parts. There's the distributed and Web part of the organization, and then there's the enterprise or back-end or mainframe or System i part of the IT organization. And unfortunately, these two parts of IT come together many times at the CIO level. And there's not very good communication, not sharing of technology, so that presents its own set of problems.

And you know, the challenge that these companies are facing and why we put this set of solutions together is how to leverage the existing systems that are running the company, the existing staff. How do they add new staff as current staff retires? And all the while exploiting the advances in middleware and technology that are presently being easier to exploit on the distributed side — things such as SOA, rich Web UI and the like.

developerWorks: What are some of the critical issues and challenges to be considered when planning for an effective enterprise modernization?

Lindsey: Well, so we have tried to ... you know, we've talked to many, many customers and talked to analysts, talked to system integrators, our business partners and the like, and we've tried to break this down into five different areas of dimensions. And we're very careful when we're talking to customers to say, "Now we're not suggesting that you start with all five all at once," although in most companies, they actually would benefit from doing something in each of these five areas. But look at what would give you the biggest return on investment and tackle those one or two or three areas first.

These five areas are broadly broken up into the assets that people have and the portfolio that they possess, the architecture of the systems that are in production or that will be built, the skills of the people who are maintaining the assets and building the applications, the processes and tools that those people use, and then the investment that the IT organization is making in support of all of this. So those are the five areas that we try to talk about.

developerWorks: So, Hayden, considering those five, let's take each one, if you're OK with that, maybe and talk about what it means and the related IBM solutions if you would, starting with asset modernization.

Lindsey: Yes, Scott. So the problem here, the issues and challenges that see most companies facing is that they do not have an electronic inventory of their IT assets. And by assets, I mean the software assets, not physical machines. And by not having that, you're ending up relying on humans to give you just mundane information like what is the impact of a change. Or if you're trying to do some project planning, this is going to take time because you have to ask people. And then, you know, someone may be on holiday, and the next thing you know, a simple planning exercise can take days and even weeks vs. the ideal solution is to have an electronic inventory of your software assets so that you can do these things 1) repeatably and 2) in a matter of seconds or minutes, rather than days and weeks.

And so of course, this has the added advantage of, you know, some people think about the fact that if you don't understand the software assets, that you have they're a liability. If you do understand them and have some meta data about them, you have graphical views, ways of learning about them, you have the ability to query and do very quick impact analysis, all of a sudden, you're unleashing the value that is in these existing assets, and now they're no longer a liability, but in fact they're an asset.

And so when you think about things like SOA, for example, it's going to be much easier to move to higher degrees of reuse — reusing existing code — than it would be if you didn't have such a metadata repository or software inventory.

So we have a couple of products here. WebSphere® Studio Asset Analyzer helps you create this enterprisewide, multitechnology inventory. And then another product is called Asset Transformation Workbench. This is about not only creating an inventory and in general, you do this on a project level, but actually beginning to transform the code, extracting business rules, identifying potential services and the like.

developerWorks: That makes total sense. Now I'm wondering the next one you mentioned, of course, was architecture modernization. And as you talk about that one, the issues around that one and the solutions, I'm also wondering your thoughts about, you know, we hear IBM talking now about Smart SOA, and that's part of some new messaging announced recently. How does that tie in here along with the other things you want to say on this one?

Lindsey: Well, our view on architecture modernization is very tightly tied to the whole concept of SOA, and of course, the enhanced view of SOA called Smart SOA.

The problem, again, going back to the issues of that IT faces, is that tightly coupled systems, ones that don't have well defined interfaces — or in today's parlance, that aren't a nice collection of communicating services — those services are inflexible. They're a source of errors, they're a source of slow development.

And so we need to move away from having those poorly architected systems and move towards a Service-Oriented Architecture style. We also believe that, for example, even before you get into coding, you need to be modeling, you know, to use less lower-level code and, in fact, do some of your reasoning and design at the business-process model levels, at the UML, more architectural modeling levels. And then transform those models, such as the UML models, into code.

And we have solutions today. I think most people understand that we have solutions for transforming UML to Java™ and WSDL and so forth. But we also can take those same models and transform them into COBOL or our new business language called Enterprise General Language, as well as Java and WSDL. So the solution for us here is absolutely — you could take the message and turn it around and say, "That's not an enterprise modernization message. That's an SOA message." And that's because these things are not distinct, and they have significant overlaps.

And so our solution is to focus on the A, the A in SOA stands for Architecture. Think about modeling before you write code, architect your systems as a set of communicating services independent of whether or not the service is going to be deployed as a Web service because the architecture needs to be consistent even if the code is going to be running under CICS® or a J2EE application server, such as WebSphere or what have you. And so we have a number of products in our portfolio that support this — a couple of notable ones.

The new product we introduced in April called Rational Business Developer Extension. This is our support for the Enterprise Generation Language, which I mentioned is IBM's new business language. In that language, we have service and interface as keywords. So this helps push the concept of SOA all the way down into the implementation.

And we have some additional capabilities in our Rational Developer for z product — something we just made available at the end of last month, in September, that has a capability called the Service Flow Modeler. This lets you wire together CICS transactions or screen interactions just like you might be doing if you're wiring together activities in the WebSphere Integration Developer product. But when you deploy, you can deploy to the control of CICS, rather than deploying to the WebSphere process server, for example. So this allows you to continue to do the same types of activities to continue to think about your systems as communicating services even when certain portions of it don't need to be orchestrated by a process server.

And of course, we can generate Web services from existing code for any of the languages that we support — Java, COBOL, RPG, PL1, EGL, and the like.

developerWorks: Very good. Now, Hayden — the next one you mentioned, the next modernization focus was skills. And when I think about that one, I automatically think there must be some real parallels to what you were talking about with asset modernization because obviously, the skills and the knowledge in an organization certainly represent assets that you want to carry along. What are your key issues with that one and solutions there?

Lindsey: So, Scott — you're very astute because what typically happens is folks focus on the things, you know, the assets that are, or the systems that are running, the systems that they're going to be building, and too often they forget about the people that are building those things, the people that are maintaining the existing systems.

And so this is one of the very critical elements of enterprise modernization. What happens is that unfortunately, many of the technology providers, IBM included, have allowed too much of the middleware technology to surface through into the programming languages that people use. And what has happened is that let's take a midsize, you know, larger company that has 500 developers. They wind up with what we call skill islands or skill lock-in, where instead of having the flexibility of moving those 500 developers around to the project that is most critical at any point in time, they have to remember, "Oh, well this project is a CICS COBOL project" or "This on is a J2EE project" or "This one is a PL1 IMS or an RPG, you know, System i project."

And so the flexibility is actually reduced in the organization down to those smaller pockets of people. And this is really not good because most businesses would prefer to have a pool of business developers, people that understand programming, but they spend more of their time understanding the nuances of the domain of the business, rather than having to be technical professionals who keep up with the latest advancements in middleware. You know, that's the job of IT companies like IBM.

So to solve this problem, we have created this Enterprise Generation Language introduced in the new Rational Business Developer product in April. And the whole premise of that language is to hide the complexity of various middlewares because you see the same patterns over and over and over again. You need to do transaction management in a J2EE context just like you need to do it for CICS or in DB2® store procedures or what have you. So we've abstracted those concepts and then allow the developer to focus on just writing the program that says "At this point, I need to commit that transaction," and we worry about how to map that down to CICS and COBOL or to Java and J2EE.

And one final thing here: This is an area we support all the platforms that our customers need. It's like 14 or 15 platforms spanning all, you know, CICS, IMS, z/OS® batch, J2EE, native Linux®, UNIX®, Windows®, and so forth.

One concern customers have asked or had over the years is well, "Hey, this is a proprietary IBM thing." And at the moment, that is a true statement, but we are working with the OMG to standardize this language, along with the some other industry partners. Because we all believe, all the people that are participating in this and many others, that there's no reason to give up on language as an important way to manage complexity. And the fact of the matter is we have great languages in COBOL and RPG, but it's time for a new business language.

developerWorks: Now the next one you mentioned — processes and tools modernization, I think. And I guess you're in this one you're obviously talking about that gap between the distributed and host environments and how that's still something that we're overcoming, right?

Lindsey: Yes, absolutely. And so, you know, we characterize it as the two development islands. Generally, they come together at the CIO and unfortunately, you know, the majority — unfortunately for the folks working on the mainframe side or the System i side — the vast majority of innovation in the last 20 years has occurred in t he distributed space because of the early days of stand-alone workstation solutions, and then client-server, and now the Web. And what this causes is additional cost because of the duplicate infrastructure, quality issues because most systems actually span the you know, mainframe side or System i side and the distributed.

And of course, there's again people inflexibility just like we talked about around middleware and language. The tools that people use and the development processes they use also limit your ability to move those people from project to project if you have something totally different for one side of the shop than the other.

developerWorks: Right..

Lindsey: So our view is to move back to a consolidated development environment — to have the same processes and tools, to have the same change and release management, to leverage the advances in our quality management solutions, project management, build management — and do this across the enterprise. Now, you can't do it all at once, but pick the thing that you think will have the biggest return on investment and start moving in this direction.

And we've made some enhancements in our portfolio, for example, with [Rational] ClearCase® to allow ClearCase to manage COBOL, to manage PL1 so it can kick off a COBOL build, give you build results just like it can do for your Java code or the C++ code. And we've done that across the portfolio. Even our new acquisition or the acquisition from last year with Build Forge that does build management — we now have a z/OS build agent and an I5OS build agent. We have the ability to do automated testing for 3270 and 5250, etc. We've even customized the trademark, you know, Rational unified process to have customization specifically for doing development for the mainframe. And last but not least, of course, is all o f our IDEs for doing RPG, COBOL, PL1, assembler — all of them are modern Eclipse-based IDEs that are exactly the same type of desktop platform that the Java or C++ or JSP developers are going to be using.

developerWorks: Hayden, we've got one more issue here to cover, but before we go onto that one, I'm wondering how is it going delivering that message around the mainframe for you. I mean, it seems like such an obvious point to be made now. Are you still finding that that is in some ways a tough story to relate or are people getting it?

Lindsey: I believe people have always sort of understood this. But I think people are moving off the position of inertia that they may have been in for a number of years. And businesses are really realizing they need to do something here. It's partly because of the continuing aging of the existing systems. It's partly because of the new momentum of things like SOA, where companies realize they really do have substantial value in the existing systems, but they've got to figure out how to tap into that. And it's based on, you know, the fact that the population of people who wrote those existing systems is not getting any younger, and they've got to figure out how to bring in new talent. You know, a new kid coming out of school doesn't particularly want to use a green-screen editor to edit their COBOL and build something for CICS. So we need to give them more modern things to make it remain appealing.

developerWorks: Well, you know, maybe that does lead into this last one, too. Investment modernization was the last one you mentioned. And what about that? What are the business factors impacting this one and how you free up what you need to funnel into this modernization?

Lindsey: Yes, exactly. And so this is the classic maintenance-burden problem. The latest data that we have says that anywhere from 75 to 80 percent of most companies' IT budgets are spent just keeping the lights on. Keeping things running that have, are already in production. And so this gives you basically what we call budgetary inflexibility or, of course, the budget is used for a large part to pay people, so it also affects people flexibility.

And so unfortunately, this percent spent on maintenance has increased through the years. And so we need to figure out ways to let this plateau and then hopefully decline. And so it's really all about increasing productivity, eliminating unnecessary work and moving toward standardized processes and tools.

So here we have many solutions, and it will touch on some of the ones I mentioned previously because it's just another way of looking at them. But just to give a couple of examples, we have facilities in our Asset Analyzer and Application Transformation Workbench products to help you find and eliminate dead code. Well, surveys tell us that anywhere between 15 and 25 percent of the code in production is not reachable ...

developerWorks: Wow.

Lindsey: ... is not being executed. Exactly. And so if you're spending time propagating changes through that, you're wasting a tremendous amount of people's time, so get rid of it. If you're going to outsource your systems, get rid of that dead code before you pay an outsourcing organization to maintain it for you because they're probably going to do it based on lines of code.

There's many other things. Just test automation. Automate your test cases, don't continue to waste time doing things by hand. Use modern IDEs, use higher-level languages, such as our new business language, which is, of course, also about higher productivity, not just about people being able to work on projects for different platforms. And one final area that's sort of a specialty program that we have, many companies are stuck paying generally fairly high maintenance costs on older platforms and languages that are no longer being actively maintained. Things like Natural and Cool Gen and Ideal and Tell All and then older versions of VB and Power Builder and the like. And so we have a practice to help move those applications over to EGL but more importantly over to the Rational software delivery platform. So that's another way both on the cost point of view and also on a productivity point of view to actually get this maintenance burden somewhat decreased.

developerWorks: You know, you use that term flexibility there and earlier, as well. From a philosophical standpoint, is that really the word that kind of captures a critical quality that has to be present for all this?

Lindsey: Yes, absolutely. So and of course, we're using that word intentionally because that's what it all about. We're not in the business of IT for the sake of IT, you know. IBM might be because we're supporting other companies. But most businesses, banks, government agencies, insurance companies, retail, what have you. Those are their business areas, domains, it's not IT. IT is a supporting organization. And so if IT cannot do the things that those businesses need, if it's not as flexible as those business want it to be, then that's damaging the business. And therefore, I think this is critically important and I believe most ... I've been on the road for like the last 18 months talking to as many customers as I possibly can and I think most companies recognize this.

And it's really be just a matter of how do you get started and which of these dimensions seems to be the thing that would return the most value, the most quickly to a particular company.

developerWorks: Would you as kind of a wrap-up thought around all of this, would you characterize this, this modernization as for some or for many businesses as being as important as issues of progress and moving forward and maybe in some cases surviving?

Lindsey: I think absolutely that's how I characterize it. It's all about enabling the business to do what the business thinks it needs to do to remain competitive, to get a leg up on the competitors and in some case adapt to what a competitor has done who's made some market changing move. So if IT were not a key underpinning of the primary business processes for these companies, then it would be less important. And so for a little mom-and-pop shop that may be the case.

But for most companies, IT is a fundamental underpinning and, therefore, needs to be treated as a first-class business process just like customer relationship management or inventory management. And as such getting IT to be more flexible and modernizing what exists, both people and assets, processes, tools is absolutely critical.

developerWorks: Hayden Lindsey, Rational vice president for Enterprise Tools and Compilers. Hayden, appreciate your time very much, thanks for doing this.

Lindsey: Thanks for the opportunity, Scott.

developerWorks: Learn more about this topic of enterprise modernization at ibm.com/rational/modernization. We've also posted a number of resource links on things Hayden covered in the show notes for this podcast. You'll also find a complete transcript of the discussion there. Find it all at ibm.com/developerWorks/podcast. I'm Scott Laningham. Thanks for listening.

Resources

• Rational Enterprise Modernization -- demos, white papers, case studies, etc.
  
  
• Podcast blog
  
  

About the author

Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments