Is there any way to orchestrate enterprise mashup efforts from the top down?
This is an interesting question because it can be interpreted in a few different ways. Integrations achieved with enterprise application mashup orchestration can be divided into three separate columns: encouragement, facilitation, and governance. These three approaches, coupled with cost-benefit analysis around solid metrics can provide the baseline for a successful application mashup management campaign.
Encouragement of application mashup use
The first facet I would like to address is how management can encourage application mashup use. Since mashup-building has a very creative aspect, it might seem like a behavior that has to emerge on its own. But a firm can do a lot to push this type of activity along. One common practice is to hold regular “Code Jams” where employees are encouraged to set aside their regular work - often just for a few hours - and build cool solutions. The only goal is to make something that will impress your coworkers. Prizes might range from simple bragging rights to kitschy gadgets, gift cards or other casual rewards.
Companies like Facebook regularly use this technique for bringing their employees together outside the normal structure of IT. Traditionally, the entries don’t have to be mashup-based, but you can make “combining two or more new or existing systems” a requirement of any Code Jam you set up.
There is also the famous “20% time” approach popularized by Google. The basic premise of this method is that employees are encouraged to spend one day a week working on something outside their regular responsibilities. This time can be used to create something new, or fix something that is broken. While most firms probably can’t make such a major commitment, setting up smaller periods devoted to innovation can again spur exploration that in turn leads to new mashups being created.
Facilitation of enterprise mashups
To further facilitate these two approaches toward encouraging enterprise mashups, management can make sure that developers have the resources they need to create mashups. This might mean ensuring that developers can easily obtain access to different internal systems for pulling data. Opening up proxy servers so that employees can get to external sites that publish useful APIs is helpful. Making sure open-source and/or licensed, commercial mashup tools are readily available is a big plus.
In this respect, mashup-building isn’t very different than any other development work. If you want individuals or teams to get a job done, you have to make sure they have the right tools and data to get started. When solving a problem or supporting a system is part of employees' normal responsibilities, then they will go through the pain of getting the access and tools that they need to get the job done. But most people won’t suffer this burden as part of trying to create something new. If you want to bolster innovation, you have to make the process as frictionless as possible.
Governance of mashups
Lastly, I wanted to touch on the governance implications of this question. “Orchestrate” has this connotation of some type of forced coordination occurring between potential mashable components. There are good reasons for thinking about this at a high level. If different systems expose data with primary keys that can’t be reconciled to one another, for example, it becomes nearly impossible to mash their contents together. Or worse – developers start making incorrect assumptions or inferring connections which might break down the road.
I am hesitant to recommend some type of Data Dictionary as a strict prerequisite for enterprise application mashup creation because my past experience with these types of projects has proven them to be cumbersome efforts that are almost antithetical to the mashup experience (and rarely bare the promised fruit, I might add).
I would rather see interfaces created that focus on the data-mapping problem itself. I have had a hand in creating several APIs of this type myself and found that they quickly become the foundation for many other mashups. Not surprisingly, when a firm has data-mapping problems, you can almost guarantee that there are multiple systems and workflows begging to be mashed together.
At the outset, I mentioned there were multiple ways to answer this question. That dovetails nicely into my final piece of advice for management. Inevitably mashups will offer multiple solutions to the same problem. A company needs to recognize that mashups have a Cost-of-Ownership (COA) just like any other product.
At some point, the mashup tree needs to be pruned in order to stay healthy. Management will need to decide which solutions should be supported, and which should be decommissioned. Traditional measurements around scalability, reliability, adaptability and cost are good places to start. Treating mashup solutions as first-class products of IT is the final step for establishing their credibility in the eyes of both developers and end-users.
This was first published in June 2011