Can we change the secret sauce of IT?

The value of IT.

Connecting disparate systems is one of the main value services that Information Technology teams offer to business customers. I used this point at a presentation before employees that are not in IT to answer the question “what does IT do?”. If you are not in IT you see this each week when you send or receive communications with a different company, wait for financial roll-ups from an operating company, or query product related information from an online catalog. Behind the scenes there are programs running to collect and manipulate data for presentation in a way that helps drive business processes.connections

Chris Curran of CIO Dashboard recently posted about the changing landscape of Information Technology integrations. Curran expresses a view that, “In reality, success is predicated on achieving consensus between all participants on a common data model.” He was referring to a concept known as service oriented architecture (SOA) in which IT teams make integrations more consistent by creating a common service for subscribers to call. As as simple example, we might create a tax service that takes an address as input and returns the tax rate. There is no need for everyone to write their own tax service when the call can be standardized. But what happens if the service is more complicated and involves transforming data? Some services may take an order for multiple products and decide if the order goes to a single fulfilment location or if it splits to multiple locations. The service may have to decide the naming of attributes for the products (size, quantity, material, etc.) Now each participant or subscriber must agree to the business rules and logic in the data. As the service grows with more subscribers then each time a change is made it requires oversight and agreement between all the subscribers.

Making spaghetti.

Is this type of architecture “increasingly untenable” as Curran suggests? I agree that it leads down a path that can create one-off solutions and is not scalable. In my experience, the “project driven” approach of organizations is a common factor that leads to this result. Reality is that:

  • Bigger organization or the one with upper-hand in negotiations tend to dictate the communication protocol and systems used.
  • The organization willing to expend IT staff often dictate communication protocols.
  • Organizations want to integrate applications because this is what their employees see and feel to transact business. This tends to lead to one-off solutions.

Can we untangle the spaghetti?

The thought of furthering consolidating and centralizing services is appealing. Curran suggests that published APIs are part of the solution. This does put the onus on the subscribing organization to consume the service and keep their own business logic local. But not every customer my team services is willing to pay an IT programmer to write code to an API. Integrations are often influenced by which side of the integration offers programmers to create the solution.

As organizations move more of their operations “to the cloud” or to overseas programmers they lose technology workers with the institutional knowledge to help write business logic. I think this will lead towards a tendency to use established services rather than writing new logic by using the API.

At the end of the day how we do integrations may change a little as we develop new options for how to integrate. But people, data, and money will continue to dictate how business gets done. More times than not, it’s the speed to market that often wins over the best way to accomplish a task. That doesn’t make it best solution and often contributes toward solution spaghetti, but it is reality.

Onward and upward!