Blogger: Craig Roth
Burton Group was founded as a special kind of analyst firm - one that is specialized in infrastructure and is able to go deep technically. Accordingly, our Collaboration and Content Strategies service was founded on the premise that collaboration, content, and communication have become infrastructure as well.
Many users still think of email as an application. Part of it is. But the vendors realized a while ago they needed to carve out the parts of email beyond POP3 and IMAP4 that should go on the server, named them Domino and Exchange, and now they are treated like infrastructure with service levels, backup/recovery, contingency plans, farm scaling, and operations-minded folks in charge of it all.
Well, Microsoft Office is an app right? Sure, until Microsoft realized they needed to carve out the parts of Excel that could go on the server and created the Excel Server part of Microsoft Office SharePoint Server. A Powerpoint server is rumored to be in the works too. And Office Business Applications (OBAs) are being created on the principle that Office is infrastructure that can be reused. It can be repurposed to produce applications that treat Office as infrastructure, connected to line of business apps, rather than a hermetically sealed application.
Well, SharePoint is an app right? Bingo! That's where this gets you into trouble. It has a purpose built front end and a wide and deep pool of infrastructure underneath it. When the purpose built part doesn't do exactly what you want, it can be a long fall down to the deep pool underneath. SharePoint buyers should understand that as much as the initial demos look like an application, really they are buying collaboration and content infrastructure. If you go into SharePoint thinking it's an app because the demos or out-of-the-box test install you did seemed to do what you want, you can be very surprised when all of a sudden this starts looking like infrastructure. You quickly move from being an application owner to an infrastructure owner and those are very different hats to wear.
As the infrastructure nature of communication, collaboration, and content (I'm including content creation in this category, not just what WCM or DM tools do) is being properly realized, we're seeing a separation of what used to be considered "applications" into infrastructure with an application on top. The infrastructure parts keeps getting thicker (such as email going from POP3 to Domino and Exchange). Accordingly, there needs to be more awareness - from end users and from vendors - of how the transition is made from application to infrastructure.
The transition is difficult, but doesn't need to be as painful as it has been. Not if vendors recognize quickly what parts of their apps need to be pulled out and treated as scalable, reliable, reusable infrastructure and are clear about the depth and solidity (how far are you likely to get before needing to call for a team of coders, is this supported, etc) of the applications layers they provide on top. Enterprises need to set up management processes and organizational structures to catch new infrastructure as it sinks from the application layer down into their domain and to understand the difference between infrastructure capabilities surfaced in a demo sort of UI and real applications.
Infrastructure has special characteristics that applications do not have and that can stymie implementers of communication, collaboration, and content technology (such as discussion groups, document libraries, portals, and wikis) that seems like an application at first:
- Infrastructure (with regards to the kind of communication, collaboration, and content software we're talking about here) needs an application to be useful. Will a little bit of customization and tweaking to the out-of-the-box UI and templates be sufficient to act as an application? If not, who is going to design and build your application now that you have the infrastructure?
- Infrastructure is meant to be reused and repurposed, so who is going to own something that will be leveraged by a multitude of groups? Probably not the first team that wants an application - if that's the case it will be game to see who can stand on the sidelines the longest and let the first, most desperate group that needs an app take the plunge and wind up owning and paying for the infrastructure the groups on the sidelines will now leverage.
- Infrastructure needs to be managed. It needs availability (according to negotiated service levels [SLAs]), contingency planning, backup/recovery. This is stuff that tends to be considered boring and "not in my job description" for programmers and power users.
So the next time someone shows you the interface for a great looking communication, collaboration, or content tool, think about stepping back and saying "That's great infrastructure. Now who builds the app on top of it and who manages the infrastructure?"
Comments