In the 13th edition of the Architecture Journal, Larry Clarkin and I wrote an article on Enterprise Mashups. You can find a PDF of the journal here. The two of us actually presented the paper at the Strategic Architecture Forum (SAF) in Redmond which is a gathering of about 100 enterprise architects, CIOs, CTOs and the like.
Our basic thesis is that Mashups, while most famous in the consumer space, are gaining traction in the Enterprise. We also lay out the common architectural tenants of all Mashups and explore the critical success factors that you will need to ensure inside the enterprise. Hopefully I’ve convinced you to go read the article at this point. Without stealing all of the thunder from the articles, it was fun to see our basic premise and prediction come true already. Larry pointed out in his write up about the article that we had quoted a McKinsey study that said that only 21% of enterprises that they surveyed were considering Mashups in their enterprise. 2 days after our article was sent to the press (48 hours too late to put this in the article itself) the Economist published a survey had that number doubling to 42%. It’s good to be right.
The discussion at the SAF was a round table discussion with Larry and me leading. We had a great conversation with a lot of good questions. I can group the vast questions into three large buckets:
Enablement and Governance were the two largest parts of the discussion. How do I safely allow more people to create mashups without compromising the IT department, the data and everything that we hold near and dear? The fear, that I think that we resolved, is that this is the Excel or Access database of this generation and that if we as the IT department don’t have control over it that we will have the wild west and everyone will be working off of non-record data. The counter point is that if someone is creating a mashup with approved services, they are actually leveraging the authoritative data source rather than creating new rogue ones. One of the companies had counted 85 different access databases with pricing information in them. That’s a bit hard to manage and needs to be reigned in because that’s not just 85 different databases, that’s 85 different versions of the truth out there and you have to ask yourself why would all these little departments create such a database. Really it’s to solve a business need that the IT department wasn’t solving. That might be access to the data or a certain twist on the data or any number of things but it’s pointing out that the IT department is not aligned with their business in the way that they need. A solid and flexible service in front of authoritative pricing information would go a long way to eliminating the need for those other databases. But the problem is potentially deeper than that.
Denny Boynton (who was moderating the discussion for us) asked the question, if we govern access to the data appropriately – is that enough? The answer from a lot of people was that governing the data was an 80% solution. But the reality is that there are certain types of data that shouldn’t be mashed with other types of data. There are conversion issues if the information is not uniform. There are filtering issues because every department has their own idea of what is a “valid” this, that or the other thing. All of these could be potential blocking issues and should definitely be concerns.
One of the interesting analogies that came up was cars and roads. As roads are built, people are enabled to drive to new location. We are not trying to control where a particular person or car drives. We do control the traffic through what roads we build, which roads are 1 way, where we put stop lights, speed limits and more. In a similar way, we are enabling people to do many different type of activities by building out services. We are not going to be able to prevent all wrecks. That’s a problem. It’s scary. The other issue is that if you watch the news, you hear about the 4 wrecks that happened on the way to work while you hear nothing about the 15 million that made it to work without incident. Similarly, the scary part is that there will be mashups that will be the IT equivalent of a wreck. There will be mashups that use data in ways that you were not intending or expecting. More often than not, these are answering some business need that you didn’t foresee and couldn’t fulfill. That enabling position rather than the one that is trying to do it all. It’s like building out railroads. The rail system only goes so far and then people get off the train and into cars.
The end result is that we have to build a core competency in SOA. That’s building out and governing the services that your constituents need. Sometimes those constituents are others in the IT department, sometimes they are from marketing or finance or manufacturing and so on.
From a technology standpoint, we talked about Popfly and Sharepoint in particular. Popfly is an amazing set of technologies and it’s going to change the way that we architect systems in the future. Denny Boynton wrote a fantastic article on it called “Is the Future of Popfly…In the Enterprise?”. John Mullinax also has posted on “building brand and transcending walled gardens” However, it’s really aimed at the consumer at this point in time. There are a couple of big things that it’s missing before it’s an enterprise level toolkit. The big one is that it’s not able to really leverage secured web services. Another big one is that it’s not hostable inside your own firewall and therefore not able to leverage services that are internal to your organization. These are just the current speed bumps but I’m sure that more tools in this vein will be coming soon for the enterprise. The other questions that we had were around Sharepoint. The reality is that there’s nothing specific in Sharepoint that does or does not do mashups. It’s a great portal site that does a lot work for you but it’s not specifically a mashup tool. That’s not to say that there won’t be tools built into Sharepoint in the future – but I don’t know what the product roadmap looks like.
Writing does not come easy to me. I feel very natural in front of a crowd but the act of writing is quite painful. I just want to say very publicly – Thank you Larry for making me go through the process of getting our joint thoughts down on paper for the journal. It’s been a great thing to have done.