And Now, Once More, the Portal Revolution
By Rob Williams
Despite a glacial emergence from the cocoon, Portals are still shrouded in a cloud of mystery. Not so much due to complexity, but because they are a container technology, so invariably, people get the concept of what a portal is by understanding what it contains, and these days, it can contain a lot. Often, when asked for a definition, the first response will be 'Yahoo! is a portal.' But that requires a follow-on definition: 'you can setup your own stock portfolio, your banking information, then choose your news-feeds and even your horoscope.' By extrapolation, we imagine that an enterprise portal is a way to setup personalized views of company information. But alas, this gets us to something tangible, but not complete. Yes, portals are used for EIS (Enterprise Information Systems), but increasingly, portals are also becoming the vehicle for a whole lot more: business activity monitoring (BAM), business process management (BPM), enterprise collaboration software, and now, with no less than Bill Gates blowing the heralding horns, corporate blogging! As is often the case in IT, things that are containers end up being hard to understand for the counterintuitive reason that there are few things that end up being excluded. Despite this undeniable state of affairs, portals are finally achieving liftoff, and rightfully so; they really do represent a revolution.
How did we get to this state of affairs? Well, it is rather astonishing that 20 years into the personal computer revolution, software has been written solely to service the operational side of the enterprise. The mad rush to operational automation climaxed with the ERP boom and bust that occurred 15 years in. By the end of the 90s, ERP was starting to look like a straightjacket, appropriate for manufacturing where production cycles were fixed and lasted years, but the vast majority of the economy seemed to be forcibly embracing agility. Agility implies responding more quickly, and then adapting, which raises questions about a system where there is any space between the person at the control (the operator) and the people in the know who are in steerage (executives). During the operational software build-out, the dream was automation on the operational side, and enough information on the analytic side to know how to achieve optimal results [OLTP/OLAP]. But only the absolute top of the business food chain could afford to undertake serious OLAP and much of the pain of it came from the fact that it was a distinct, additional domain that had to be integrated with the operational domain, and kept in sync at all times, to be useful. In the old world, executives were happy to close the month 2 weeks into the new one, then run a bunch of reports and make an assessment of how they had done. In the new one, steerage is literally done by instrument: Amazon can't wait to look at the Christmas numbers to decide what to do the following year.
Of course, such agility carries with it profound costs of its own, and the effects are wide-reaching (thus the seemingly endless scope referred to above). At the top of the list of changes wrought by the portal revolution is perhaps the most revolutionary feature: the notion of a single destination that aggregates information [input side] but also grants access to a wide array of functionality [the output side]. Imagine an executive showing up to work and having a portal as his homepage in the browser, and it showing him, at a glance, views that run the gamut from recycle time of inventory to success of the fall marketing campaign (info), but also, giving him the ability to drive some of those very things from this same 'cockpit': electing to end a campaign that looks to be out of gas and launch another, or order restocking of certain items at a rate greater than the original plan because of the success of the marketing campaign. Imagine also, of course, that this exec is just responsible for this campaign and customer, and across the enterprise, others are seeing completely different views, reflecting only what they need to know, making possible only changes they are authorized to make. Now, the reason this is perhaps the most revolutionary parts is that there is no one 'thing' behind all this, no, dare I say the word, application.
Before the cart tips here, a quick recap: the portal is the container for the executive enterprise consumer, delivering EIS, but it is also the new model for the cross-operational cockpit, which is precipitating the emergence of an app-less world. While the latter may seem an ambitious conceit, a little perspective defuses that: the alternative approaches are ridiculously more precarious means to the same basic end: a realm of integrated, cooperating programs that can be used together with little to no thought. (Yes, with each clarification, another item ends up in the cart!) But really, integration became the hottest realm of software in the past couple of years precisely because so little had been done about making even the simplest things possible (e.g. displaying an inventory level on a product page). Unfortunately, of course what came out of the hatch (in return for the countless millions in enterprise revenues for the integration vendors) were simple (or simplistic) integration solutions. The dirty little secret of the integration world is that people accept yet another vendor and license fee and support contract, 90% of the time, in return for a program that pulls things out of one database and puts them in another. Once many such 'integrations' have been made, a whole new, expectedly ugly problem emerges: another thing to manage. Mind you, not just the integration software, the constituents around each solution (brokers and adapters and queues), but also, issues like security (are you allowed in to get x? are you allowed into y to deposit x?). The result is that perhaps the bridge was built and the customer is now able to see inventory, but a vast new substructure was introduced, and frankly, one that shows how feeble it is when a more complex integration is required. Solution? Enter web services.
Web services, like portals, started out as a simple solution to a common problem, and, like portals, now seem to be the answer to all prayers in their particular realm of the IT world. Most people who worked with the various pretenders to the distributed component crown (CORBA, COM, COM+, EJB) know that no sooner did we have distributed components than we figured out that asynchronous queuing mechanisms (like MOM) were actually quite handy. Web services, at the simplest level, are an attempt to marry those two worlds and using XML to remove the interop problems that come with component standards. But then, like the mechanic who decides to swap the water pump while he has the engine apart, a swarm of wrenches descended on the chassis and many more things have emerged. One of the most important is a recognition that certain things just cannot be retrofitted into every app in the world, despite the eager intentions of the many busy standards bodies. For instance, security is a major problem that becomes much worse when enterprises start to try to automate transactions that cross many application boundaries. Here is where these two worlds collide: the portal, which looked at first like television for executives, in order to move to flying by instruments, needs a way to not only reach out and touch all the various functional components of the enterprise, but a way to envisage how that might happen. As the integration vendors grew in size, the demand to tackle tougher problems emerged and breathed new life into process servers. There's a simple reason for that: imagine an integration that consists of more than just get this/put it there. It would contain things like decisions, which might be based on rules. Two things needed: 1. a process server to model and manage that 'process' [no longer really a mere integration], and 2. a way to interact with the various process participants [formerly apps] in a fashion that is granular enough that these rules-driven decisions can be made externally. (This is why all integration vendors are now selling process servers, and all application platform suite vendors are selling process-driven integration. More on that below.)
A few years ago when the Application Server vendors realized that they were not going to be able to make billions anymore from just the container, the notion of an extended offering emerged encompassing App Server, Integration, Process, Portal; Gartner coined this the Application Platform Suite [APS, of course]. At that time, portal seemed like the weak link, there to offer a mere window into the wonders of the others' world. In an unlikely turn, portal is starting to look like the piece that will end up consuming the others. The app server, already commodified, will soon be serving granular services that will increasingly be function points in a larger tapestry that exists outside the application server container, and the whole approach to products as we've known them will vanish like a mutated subspecies. While this may sound ambitious, consider the fact that an exact analogue has already happened in the world of development tools: IBM delivered, with Eclipse, a completely extensible environment with the ability to extend through plug-in and two short years later, it seems readily evident that in a short time, no life will exist outside its biodome (except perhaps competing biodomes that adopt its exact approach).
How long will it take on the enterprise side? That depends, but there are many exigencies that favor speed: 1. portal servers, traditionally very proprietary and expensive, have now adopted a standard (JSR 168) and many open source options have emerged, and 2. in places that have adopted portals, the effects are swift and powerful: executives are getting a taste of a type of empowerment that has never existed before and early indications are that they like it.
Epilogue: Another related, but tangential reason for the collapse of the app is the fact that vendors, even if they have billions, somehow, just never end up delivering everything we want, often because, like drug companies that are making billions on recreationals, there's no interest in servicing marginal markets (diseases that a mere few million suffer from). Already, the Eclipse revolution has produced a Cambrian bloom of tools from database explorers to metrics to documentation. It seems reasonable to imagine the same things will happen on the enterprise side, and as the cost of extension dwindles to near zero (adding a plug-in will be like a plumber replacing a trap), the ability to truly cover the waterfront will finally emerge, surprisingly, with much of the work coming from outside the realm of the major application vendors.
Rob Williams is a VCG System Architect. He was a featured speaker at BEA eWorld 2001 on the Future of Personalization (while in the midst of a portal project) and at JavaOne 2000 on doing eCommmerce with Nothing but Java and XML. He's been featured in many publications including EAI Journal, MacDeveloper's Journal, and Enterprise Advisor.