Blogger: Lyn Robison
Back in 2007, I wrote a Burton Group overview entitled, “Build, Buy, or Borrow: Choosing Custom Development Software, Open Source Software, Commercial Off-the-Shelf Software, or Software as a Service”. In this blog post, I will build on the ideas I presented in that paper and offer some refinements to my original recommendations.
These newly refined recommendations provide more detail and emphasis on COTS and SaaS, and add two new elements. These newly refined recommendations offer a path to an enterprise IT infrastructure and application portfolio that can be both radically simple and more effective than the burdensome patchwork of clunky legacy systems that you find in enterprises today. Here are my updated recommendations. Enterprises should use:
- COTS software for the front-end
- SaaS for the back-end
- XML for the data
- Pixie dust (in the form of identifiers and data services) to make information float from system to system
1. COTS for the Frontend
COTS software offers flexibility with low cost, which is readily apparent when user interfaces are implemented using COTS software packages on PCs and mobile devices. Certain COTS packages (namely browsers, media players, word processing programs, and spreadsheet software) can become low-cost, flexible user interfaces for enterprise systems. They can display all kinds of information to businesspeople, including narrative text, graphics, photographs, video, audio, structured or tabular data, charts, highly structured documents, electronic forms, etc. And these off-the-shelf UIs can go beyond simply displaying data -- they can let businesspeople edit data and submit it to backend systems for data processing and storage.
COTS packages such as browsers and productivity applications are low cost UIs because IT developers don’t have to write much, if any, UI code. These COTS packages also sport interfaces with which businesspeople are already familiar. Browsers and productivity applications run on multiple clients, including PCs, Macs, and lots of mobile devices. Clearly, if the data is HTML, OOXML, ODF, or some other readily-consumable format, browsers and productivity application software can make highly flexible, low-cost UIs for enterprise information systems.
For a demonstration of how well browsers can display various kinds of information, use your favorite browser to look at the World Wide Web. For demonstrations of how well COTS software can provide highly-flexible UIs for enterprise systems, see the templates here and here. In the SLA example, IT and businesspeople could use this SLA form to create a new SLA or update an existing SLA, which could then be saved to a backend database that stores OOXML data, and that could be queried by IT professionals whenever they need to know what service levels are expected of them. The Expense Report example is a template that could be customized and used as the UI for an expense system where employees could fill out the spreadsheet that they then save to a backend database that can validate OOXML data and process the expense reports.
2. Saas for the Backend
Saas offers the fastest time to value for generic business processes. SaaS is most appropriate for those business areas where the processes are standardized. I’ve seen lots of enterprises where businesspeople believe their processes are “different” and cannot be automated using standardized business software. In many cases, however, these processes are “different” because they are actually substandard. IOW, if businesspeople would adopt standardized business processes and the pre-built SaaS packages that can automate those standardized processes, they would significantly improve their business. In those cases where the data is too sensitive to trust offsite with a SaaS vendor, then the SaaS application often can be hosted within the enterprise’s data center. SaaS is a part of cloud computing, and enterprises should consider internal, private, and public options for cloud computing, as their security requirements dictate.
3. XML for the Data
When data is in XML, thousands of existing software packages can handle that data. Data in XML is universally approachable, accessible, and usable. Many IT professionals think of XML only as a format for transferring data between applications, which is a counter-productive perspective. More than just data transfer, XML is a powerful format for data storage. XML is a useful compromise -- XML may not be perfect for structured data or for unstructured data, but it is a useful compromise that can handle both. The Microsoft Office suite and the Open Office suite store their data (their documents) in XML, which clearly demonstrates that XML works great for narrative text storage as well as for structured data storage. As further evidence of how far XML can go, check out a demo that drew gasps at TED2010. The file format for Photosynth and Deep Zoom is XML-based.
4. Pixie Dust (in the form of identifiers and data services) to make Data float from System to System
This is best illustrated by a couple of examples. Since Gartner’s acquisition of Burton Group, we have been getting up to speed on Gartner’s internal systems. I have learned that I have at least three IDs with which I must log in to various Gartner IT systems. If Gartner ever needs to combine the data about me that resides within these various systems, they would have a tough time doing it. How do you do cross-system joins of important data when the identifiers are not consistent between the systems? It ain’t easy.
Here is another example. Within Burton Group, we have multiple systems that contain customer data. Two examples are our CRM system and our Catalyst registration system. If I want to find out the customers who are attending Catalyst and who have had recent dialogs with my team, I immediately encounter the problem of customer identifiers that don’t match between those two systems. I can try to use email addresses as identifiers -– which is about my only option, but that makes my task far from easy. If we used uniform identifiers throughout our disparate customer systems, I could use simple UI tools such as my browser or even Microsoft Excel to find the customers who are attending Catalyst and with whom we have had dialogs recently, and I could do it without building an elaborate data warehouse and an expensive set of BI applications.
We would need a data service or two to be written that would enable me to use COTS software to query the CRM system and the Catalyst registration system based on customer ID. Managing IDs and writing data services that work with COTS UIs is what MODS and the XQuery development stack are all about.
Compared to the World Wide Web, enterprise information systems are clunky and kludgey. If I want to get information from CNN, I don’t have to know any details about CNN’s computer systems. I just point my browser to http://www.cnn.com/ and I get ready access to the info I need. It is ironic that every enterprise has complete and ultimate control over its own information systems, and yet, enterprise information systems are clunky and kludgey. For example, to get information about Burton Group clients, I have to know the intimate details of our CRM system, our Catalyst registration system, and each of our other systems that might contain customer data. I cannot easily combine the data between these systems and I cannot use my browser or productivity applications with which I am already familiar to do it.
Enterprise information systems are clunky and kludgey, but they do not need to be. Enterprise information systems can and should be better than what you can find on the Web. The approach I am suggesting is to use COTS software on the front-end, use SaaS applications on the backend, use XML to store the data, and have IT developers focus on bringing data together for businesspeople, instead of having IT developers continually build more clunky applications, which only add to the growing crowd of aging legacy systems that imprison valuable data within silos and that seem to remain forever on life support in the data center.