Enterprises need to think architecture, not integration

In a blog entry last week and his podcast for this week, David Linthicum lamented the fact that many technology vendors are too focused on integration and not enough on architecture. My opinion on this is that the problem lies first with enterprises, and not with technology vendors.

In order to first explain this, I need to split the technology product space into two large groups. First, there are products that are pure infrastructure. They are platforms on which someone else builds solutions. This is the familiar space of database platforms, application servers, network appliances, EAI platforms, ESBs, MOM servers, etc. For products in this space, I have absolutely no problem with the vendors providing products that are focused on making integration easier. Does this enable enterprises to build up layers of “glue” in the middle? Absolutely, but at the same time, the enterprise had to have a need (whether perceived or real) to make their integration efforts easier.

The second group of technology products are the actual business solution providers, whether it’s a big suite from SAP or Oracle, web-based solutions like Workday and, or anything in between. These vendors absolutely should be focused on architecture first. At the same time, I don’t think many of these products are being marketed and sold on their integration benefits, they’re being sold on their business capabilities.

So, what’s the problem then? The problem comes when the enterprise IT staff involved with technology identification and selection is too focused on integration, rather than architecture. Almost always, when I hear an enterprise talk about integration, it’s a just in time effort. Someone is building some new system and as part of the design of that system, they decide they need to talk to some other system. No thought of this need occurred in advance from either side of the integration effort. In putting together the solution, the focus is simply on the minimal amount of work to put the glue in the middle. As long as this trend continues, the infrastructure vendors are going to continue to market their products to this space. While it’s a noble quest to try to educate and market at the same time, it’s a risky strategy to present using a different mental model than your target audience.

The change that needs to occur is that integration needs to be a primary principle that is thought about at the time a system is placed into production. Normal behavior is to build a solution for my stakeholders and my users, and not think about anything else. In past posts (here, here), I’ve talked about three simple questions that all projects should start thinking about. One of those questions is “What services does your solution use / expose?” How many projects actually identifying anything other than just what their front end consumes? Does anyone see this as a problem? Let’s come back to the infrastructure vendors. They actually do need to think about architecture and services, but in a different space- management. I’ve railed on this in the past. How many vendors expose all of the capabilities in their user-facing management console through one or more service interfaces? If I want to embrace IT Systems Automation, how on earth am I going to do this what what these vendors give me? I’m not. I’m going to have to leverage management adapters in more automation environment. Does this sound familiar? It sure sounds like EAI to me. The best way I see to address this is think about integration in advance. Don’t think about it at the time someone comes and says, “I need to talk your system,” think about it at the time you build your solution and ask the question, “How will other systems need to interact with this.” Yes, this is a bit of predicting the future, and we’ll probably expose things that no one ever uses, but I think an enterprise will be in a better state if they try to anticipate in advance, thinking about architecture, rather that continue with today’s approach of integrate on demand.

5 Responses to “Enterprises need to think architecture, not integration”

  • Rob Eamon:

    “My opinion on this is that the problem lies first with enterprises, and not with technology vendors.”

    Absolutely. We are in violent agreement on this one! 🙂

    “These vendors absolutely should be focused on architecture first.”

    Here, we may disagree slightly. It is *still* the purview of the enterprise to determine their own architecture goals and principles. Certainly Oracle and SAP need to have a reasonable architecture for their big components. And these components will have a big impact on an enterprise.

    But those broad applications still shouldn’t drive the architecture of an enterprise. Significant influence, yes. But the enterprise must fit that large component into their own architecture–Oracle, SAP, et al can do it for them, but they may not be happy with the result

    Linthicum really seems to be picking on the vendors of late. Doesn’t he recall that he 1) was one “them” (SAGA) and 2) still is!? 😉

  • I agree Rob. Yes, the enterprise must be in charge of their own architecture rather than letting third party apps dictate it. At the same time, if those vendors aren’t concerned about their own architecture, they can wind up no better off than an enterprise that built their own. Just look at the effort SAP has to move their apps forward.

  • I have to say letting a vendor drive any kind of strategy for you either in a active or passive way came be a huge risk. I agree that architecture should be independent of any vendor solution. Simply gluing things together usually leads to brittle architectures that are subject to failure. I’ve seen it happen many times, a new vendor solution implemented and quickly being attacked by “integration” with no thought of overall architecture.

    Flash forward a year and you got yourself a nice set of redundant brittle interfaces (not services) that are so tightly tied into the vendor product and ungoverned that maintenance, upgrades etc become a major deal if not impossible. This situation is repeated many times in an enterprise and leads to a lot of the IT costs which is maintenance instead of value added services.

  • ” Don’t think about it at the time someone comes and says, “I need to talk your system,â€? think about it at the time you build your solution and ask the question, “How will other systems need to interact with this.â€? ”

    I’ve been pushing this mindset for years across the enterprise as part of an Integration Competency Center. But while this is an excellent and appropriate architectural approach, rarely is the business currently organized to reward this behavior. Rather, they punish it. For such an architecture leads to increased initial cost at the strong benefit of long term integration ease, decrease of integration costs, and major increase in reuse. Even further, the business itself may be educated on the benefits of reuse, but say “it’s reuse by another department/division/organization, it’s of no benefit TO ME and MY IT budget.”

    It’s kind of like design benefits making a car easier to service at some additional build cost. That doesn’t really help the car company, and the buyer rarely is sophisticated enough to realize the long term impact.

    There’s a business benefit, kind of like organizing central purchasing for a major corporation, that has to be understood within the business-IT context, to build a benefit-reward structure to motivate this behavior.

  • […] удачную и конкретизированную формулировку проблемы, о которой неÑ?колько ранее пыталÑ?Ñ? было […]

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.