How application integration maintenance is like taking care of a car

If an organization has integrated sets of applications, what must be done to keep them up to date? How can organizations avoid common pitfalls with application integration maintenance? In our latest podcast, Forrester analyst Randy Heffner offers some best practices and his predictions for software integration management.

This is Maxine Giza for SearchSOA. Joining us today is Randy Heffner of Forrester. Thanks for joining us, Randy.

Randy Heffner

Randy Heffner: Sure, thanks, Maxine.

Thanks. So today, we're just going to talk a little bit about integration management throughout an application's lifecycle. And just to start off a bit, if you could just talk to us a little bit, Randy, about what is software integration -- or rather, software integration management, an area that's covered under the umbrella of application lifecycle management. If so, yes, and could you kind of also talk about some of the gaps in that coverage?

Heffner: Well, it depends on whether you talk about application lifecycle management as a products base or as a discipline. And in a products-space sense, then I'm not sure it's covered very well, and it would be very hard to cover it very well because integration is such a diverse area. If you include the broad set of application integration, data integration, process integration and related areas that can serve an integration function or maybe not, like complex event processing and business rules.

I would even include collaboration, when done well, as a process integration, that sort of design point if you will, because what you're trying to do is integrate people in the softer context of things that need to be done as part of a process. And that's sort of a very contextualized collaboration versus just, hey, toss some collaboration or social tools into the environment and hope people use them well, which is haphazard at best anyway.

But if I think about it from a discipline standpoint, I don't think I would use the word 'application cycle management.' I would call it 'solution lifecycle management' because integration, of course, goes across the bounds of any individual application. And in the past the view has really been about integration is, well, we're just connecting silos of applications together to make it easier to live with the silos. And going forward, at Forrester we think that that's a poor view of integration. Sometimes that is what you need to do; but really though, what you're trying to achieve with integration is coherent operation of your business and excellent business outcomes. And so, you ought to start with business design as the point, so we use the phrase 'digital business design' in our research to capture that notion.

From that standpoint, then, is another reason to think of it as 'solution lifecycle management.' And as part of that, and as part of making sure that you have coherent business, you better make sure that you're managing your integration well. But that's a new view, and I don't yet see that many people in the industry taking that view and understanding that integration really is about achieving a coherent business, which is a business point of view versus the technical point of view of just connecting silos.

So, Randy, if an organization has integrated sets of applications, what's needed to keep those integrations up to date?

Heffner: Let's come from two different angles. One is just that, let's say that we have even gone through this more strategic process of digital business design that I'm talking about and we've identified particular ways that we'll integrate applications. Maybe sometimes we've done a role-based workspace that does a user interface that turned out to be the tool that a user needs, or user role needs versus forcing that user role to split across multiple applications, or you've done some process or SOA-based things in order to unify your business and achieve a coherent business out of the these multiple silos.

Well, the fact is, the silos are still changing, and if they're packaged apps that you're delivering off-the-shelf in an on-premises way, then you have some control over the cycle of upgrades and probably integration. Firms don't tend to keep their off-the-shelf on-premises apps up to date as much as they should. But if it's [Software as a Service] SaaS-based, you don't have control over when the application gets upgraded and how the functionality is going to change, so you need to be focused on understanding from both a preventing-problems point of view and also from a taking-advantage-of-opportunities point of view. When are the applications that you're tying together with your integration strategy? When and how are they changing, and what does that mean about when and how you need to change your integration with an enterprise SOA strategy, just thinking again about more internal potentially on-premises sorts of stuff?

Other projects may be creating new versions of the services that you use and eventually you'll want to upgrade to the latest version of the services, if for no other reason than to keep down operational cost, and maintenance and management hassles in your enterprise. So, these are all good reasons to have a good monitoring strategy to know when and how each one of the apps that are part of your integration are being changed to make sure that you can [make] some conscious decisions on when and how to update and upgrade the integrations that you're doing. And this is all aside from just the fact that your business is changing and may drive you to need to do new ways of integrating as well.

Randy, you mentioned integration maintenance a little bit just a second ago. What would you say are some common mistakes in application integration maintenance and management that you've seen?

Heffner: Well, probably the most common one is one that I alluded to, which is thinking that if it ain't broke, don't break it. If it's working, then just don't think about making any changes to it. But the issue with that is you can get so far behind with a packaged application that you have installed on-premises, for example, that now, all of a sudden, upgrading to the current version is a major project versus a few little hiccups along the way. So, that's a major reason to think about -- a major mistake is forgetting that you need to be looking at and maintaining the apps.

I think another big mistake that I alluded to is going at it with the mind-set that it's just about connecting these application silos, and you miss opportunities to think about achieving better outcomes, better business outcomes by introducing new models for integration and new ways of doing integration. Maybe you can push data around on the back end in a data integration, application integration kind of way. But maybe what the real problem is, your business process is broken and you need to fix it via integration at a higher level, you're doing process-oriented kinds of integration work that is undergirded by data and SOA kinds of integration. And when I say 'SOA,' by the way, we should note that I'm referring to every bit as much the [application programming interface] styles of integration, whether it's internal APIs or the kind of external open Web integration that's often called 'API management.'

If you could offer someone some best practices in this area, what would they be?

Heffner: I would say that -- let me do this two ways. Let's say that you're ready to and you see the value in taking a more business-focused approach, and let's say not. If you're ready to do digital business design and look at your business, then I think you're driving the decision to do integration work based on [a] clear analysis of business outcomes and understanding your processes from a coherent analysis and a businessperson's point of view that says what's important to this business area and [the] costs and outcomes of running that area of the business, and you're driving integration from there.

But if you're not doing that, then, and if you are, but particularly if you're not, your focal point becomes having a good monitoring system for understanding when are apps changing, how are apps changing, and using that -- and whether these are SaaS, on-premises, or custom-built apps -- for understanding how they're changing and have a continual assessment of when is the right time to update integrations. Along with that, one of the best practices that I think you can leverage from some companies in the world of SOA who've been doing good things, is to understand that there is no such thing as an application that does not have a next version, because you may need and this applies every bit as much if I'm thinking about integration paths as my application. Because even if you don't need to deliver new business functionality, you need to keep from accumulating the technical debt of having many different apps doing integration with the same apps in different ways, on different versions of SOA services and the like.

So, discipline -- I might make an analogy to car maintenance. Everybody who owns a car does or should know [that it's] important to change the oil on a regular schedule, particularly if your car is older, that one of the most important things you can do to keep the car running and to maintain its life is to change the oil. Well, it would be convenient if you could do this maintenance. I mean, you get nothing more from an immediate-benefit standpoint by going in and getting your oil changed, it's just time you have to invest.

And so, maybe it would be convenient to only change the oil when you had to do some other major maintenance, like you're getting a new car stereo installed, or there was a recall, or you had a collision and so you had to get -- so you knew you had to get some major repairs. But that doesn't work out that way. Sometimes you've just got to bite the bullet and take the time and go in and get your oil changed, that keeps it running well; and you have to have the same attitude toward your body of integrations and the body of applications that your business is running on. And so that orientation toward understanding that ongoing maintenance is a regular cost and something that, yes, you'd like to keep under control, but it's something that you need to spend in order to keep your business flowing well.

Great analogy, Randy. One last question for you, I'm going to ask you to put on your forecaster cap here. What tools, and changes, and processes do you foresee happening now, or maybe in the near future, in terms of managing software integration throughout the application's lifecycle?

Heffner: I keep hearing a lot of noise about various kinds of metadata management and similar sorts of tooling, whether it's XML-oriented kinds of modeling or just more pure data and metadata management, that may be associated with data integration or reporting or other. And I think that will play a role in helping to make maintenance of integration smoother in the future, but I think there's not really a clear path to how that happens. And so, I think there's a lot of creativity yet to happen in the industry, both on the vendor side and on the user side, to figure out how to make metadata management work very well.

An example of it is, for those that are doing both data architecture and SOA, there's two names I've heard, but you can either call it a 'common information modeling strategy' or 'canonical information modeling strategy.' I sort of like 'common information modeling' better. But there's a realization that how data gets modeled for storage in a database or the like is different from how data gets modeled to be in motion in a SOA message, or an API structure in a REST API. But nonetheless, there should be some degree [of] coherence between the two. If 'customer' is defined one way in your databases, it ought not be defined a whole different way in your SOA messages. And a common information-modeling strategy tries to find the common ground between those two, and metadata management is a big help.

I think the other major thing is the ugly word 'governance,' which we're talking a lot at Forrester about Agile governance, and I think there are ways to approach governance in the right way so that it doesn't sound like 'We're from the architecture team and we're here to help you,' which sounds likes sort of like 'from the government and we're here to help you.' But governance is an important part of this. That strategy I mentioned, of 'there's no such thing as an application that doesn't have a next version' -- that requires governance to make sure that on some schedule, before it gets too far in-between points, an application is brought up to snuff with the latest in the integration interfaces and versions that have changed for the various integration points that it has. So, I think governance and metadata would be two big keywords that I would associate with the future in this area.

Great. Well, that's all I have for you today, Randy. Thanks so much for joining us.

Heffner: Thanks, I appreciate you having me, Maxine.

All right, thank you.