Portals have grown from glorified static pages to mostly functional customer interfaces. On the way, they've grown from business satellite features to Jupiter sized objects that contain their own planetary system. Everything threatens to be pulled into their orbit and, worse, to disappear into their atmosphere. If you're not careful, your innovative idea will become a comet burning up in the atmosphere of the giant portal.
Although everyone knows how destructive their gravitational force can be, the giant portals are the path of least resistance, the ticket to expediency. Forget all architectural burdens, we'll have to get to those later... and when will that be?
This has already created barriers to RIA and mobile adoption. Tacking mobile views on to large portals and shoe-horning terse markup, like JSON, is a quick fix. Long term, however, this will prove unsustainable. In some regard, this is extending the tangle of poor architectural decisions into the scattering of internet end-user devices.
It's easy to understand that, aside from the intoxicating effects of expediency, these decisions are being made because of the following:
- The giant portal is where the data is.
- The giant portal is where the developers are.
- MVC design already prepared us for multiple rendering strategies... right?
- If we tack on to the giant portal's domain, we can tap their authentication.
What's less obvious, and not fully acknowledged, is that the giant portals are the primary external facing security interface. Beyond authentication and identity, it's the home of complex authorization decision logic and where identity attributes are pushed/copied to make it all happen.
We already have many indications of the trouble to come with the incompatibility of portal authentication strategy with services generally and mobile particularly. The identity, authentication, and authorization aspects of how big companies do IT today are on a collision course with where they want to go: cloud or, more to the point, IT as a commodity. If cloud turns everything IT into a service, how can we live with a gaping hole for services security?
The architectural principle du jour is: Never make assumptions about how people will use your API. Beyond loose coupling, this paves the way for a future where anyone can dream up a new user experience or a new business function from an aggregation of existing ones. Ideally, anyone can bring a new business function to the portfolio with little expense and time. If the API Economy is where we're going, can we tack it onto the huge portals with their nineties heritage?
I say no. But we also can't avoid the influence of the big portals. Additionally, we can't ignore the gems that lie inside: complex business logic and authorization decision logic.
At the very least, and in the spirit of expediency, we must begin aggressive efforts to abstract away the surface of the portals. Behind this abstraction and under the surface will be a mining operation, intentionally separate from innovation efforts.
Anyone who says that the work we did in portals is not important will be as wrong as those were who declared the mainframe dead back in the nineties.
It is important that we control the stifling influence of past application architecture on new and a new architecture that truly enables innovation.
Written with [StackEdit]