I ended the first part of this post (Enterprise IT in 2020 – A Minimal Viable Vision) with a list of the architectural elements and expected capabilities for Enterprise IT in 2020. In this post I’ll describe each one in detail. I sincerely invite readers to review, critique and provide feedback.
A Single Application Portal and API
Access to order, administrate, manage and monitor every aspect of the products and services delivered by Enterprise IT to the business will be via a single portal and a RESTful API. As an application owner my default expectation is to be able to manage my entire technology stack from a single portal. I shouldn’t be forced to log into a one management console for my Java application and separate one for my Database and a third one for my analytics, all of which look and feel as though they were created by separate vendors.
Quite beyond the inconvenience of managing multiple portals, the cost to the business of sustaining these disparate applications is directly proportional their number. But Enterprise IT shouldn’t dictate the use of the Portal and application teams will have the option of using an API instead. Application teams will often want custom automation of their processes and instead of being dependant on IT to deliver this (which it never will, as bespoke work is out of its remit) we will expose an API to the application teams and allow them to implement their automation or indeed any other task they wish to fulfil. Obviously some thought must be given to preventing accidental load generation, some basic rate limiting capability on the API should suffice. And finally the portal should provide full role based access and integration with enterprise directory services and other authentication, authorisation services.
There are different strategies for delivering a single portal and API including divestment and decommissioning of existing portals with a move to either invest in one existing portal and to augment its capabilities or to build a new portal that will replace all existing portals. Alternatively one could decide to freeze investment in existing portals beyond exposing their API and, using a third party product to standardise the user experience while implementing all new capabilities via the exposed APIs. In the longer run the UIs of the existing portals would be decommissioned reducing the cost of maintaining the underlying portals.
One thing I should make clear is that where third party applications provide their own consoles, and no API, it would acceptable to switch to these consoles from the enterprise portal. There is no point in recreating the functionality of these consoles. What needs to preserved is the continuity of user experience and the ability to locate and access these consoles from a single location, the enterprise portal.
The difficulty of consolidating portals shouldn’t be underestimated even with the use of the latest API management software. I personally favour investing in and augmenting an existing portal until such time where it can fully subsume other portals. Asking the maintainers of other portals to convince themselves that our strategy is the right one may be difficult. To bring them along for the journey it may be helpful to ask them to expose all of their functionality via APIs and become directly involved in definition of the target state. Rather than developing features for their existing portals, they should try to focus on what they can do for the enterprise portal.
The Application Exchange
We are all familiar with app store, markets and exchanges. They essentially simplify the consumption of products and services by doing what markets do, that is, bringing buyers and sellers together and facilitating secure and fair exchange. For the enterprise an Application Exchange extends these benefits by reducing Shadow IT and DIY IT (IT that is owned and managed by the application team rather than Enterprise IT) while increasing adoption of managed products and services. However an Application Exchange can also be used leverage the true benefit of markets, which for me is their ability to drive innovation. I have discussed EaaS, Software Defined Everything and Markets in a previous post but suffice to say that commodification of IT is an inextricable and maturing trend. If Enterprise IT is to remain relevant at all, it must stop being the Entrepreneur, attempting to second guess business innovation and instead become a Market Maker.
Creating a regulated, secure and simple environment where technology suppliers (both internal and external) to the enterprise, and technology consumers can come together to solve business problems will be the mission of Enterprise IT.
Communities, Software and Support
Centralised IT support and professional services is failing to satisfy business demands and breaching SLAs. Simply outsourcing support may have cut costs, but it is has definitely reduced quality. The only viable solution is to raise the expectation of application teams to support their applications themselves; incentivize them accordingly and foster communities to help share the knowledge and expertise. Involving Enterprise IT to support an application should be considered to be the last port of call, the nuclear option. To this end the selection of IT from organisations with mature communities should become a key consideration in any RFP and therefore I think we’ll continue to see a growth in the adoption of Community Software. As we’ll see later Enterprise SDLC is a dependency for fully realising the benefits of Communities.
Engineered Business Solutions
If anyone can come up with a better name for the concept I’m about to describe please share it with me. Currently PaaS application portfolios consist of applications such as Web Servers, Application Servers, Databases etc. Application owners would select the applications they need to deliver their business solution and then proceed to integrate their cloud infrastructure.
While the task of integration may not be onerous it still demands manual intervention which is, in most cases, totally unnecessary and indeed the source of many integration malfunctions. I have described this problem in my post the “Resurgence of Platform as a Service” were I identify “Pre-Integrated Technology Stacks” as a benefit of PaaS. For example one of the most common business use cases is for Online Transaction Processing (OLTP). I would hope that rather than having to assemble a stack from Web, Application and Database servers we would simply select the OLTP product and begin loading our business logic, knowing that we’ll have a dynamically scalable, highly available infrastructure that requires no additional configuration or integration.
In part 3 of this post I hope to complete the description of the remaining elements of Enterprise IT 2020.