This is the first in a series of collaborative posts with my technology co-conspirator Grant Matthews.
What if the only roles of the IT Department was IaaS and Solution Selection & Implementation oversight?
What if all user departments were responsible for selecting, implementing and supporting their own applications within a well defined but “solution-flexible” architectural landscape.
Strange question you might think but bear with me for a few more paragraphs. Firstly the IaaS question was placed into my head by ex-colleagues working in a highly complex and dynamic environment. Would such an approach work (and how)?
Enterprise Architecture and IT Delivery departments in large organisations with highly independent (i.e. strong minded) business departments tend to be viewed as obstacles by the business and conversely the business users tend to be viewed as indecisive, solution-focused, intransigent etc by IT. Allowing each business department to “roll its own” solutions could solve a lot of internal issues but would have to be done in a manner that;
- Allowed reasonably flexibility for the business departments
- Did not endanger the operation of the organisation
- Resulted in a self-selected but highly integrated set of solutions
- Makes IT the provider of infrastructure, core services and most importantly knowledge (i.e. consultancy)
- Makes the users 100% responsible for selection, implementation, operation of their own software.
I was mulling over this idea while out walking in my home town and stopped to admire the various yachts at the local marina. All of the yachts were different classes and sizes and continually change as the owners upgrade, downgrade or move on. The only constant was the moorings, power & facilities supply and the fencing around the marina. Now translate this to our IT questions above;
- Moorings = Infrastructure
- Power & Facilities = Common Assets and Communications protocols
- Fencing = Security, SSO, etc
- Marina/Harbour Entrance = External Communication protocols
- Yachts = Applications
Just for the fun of it lets call it the “Marina Architecture Pattern” or MAP for short. The MAP would be a layered construct with a minimum set of rigid architecture principals all applications that wanted to be “docked” into the MAP would have to adhere to.
The MAP layers, referred to as the “Backbone” would be as follows (from foundational to operational);
- Infrastructure – Mix of on-premises, off-premises DC’s and cloud.
- Bulk Data Transfer
- SOA / ESB
- Rules and Process Engines
No business department would be allowed to purchase software that copied or duplicated any of the above layers, cloud solutions being an exception for the infra layer. Any software purchased would have to utilise / integrate into the MAP Backbone. The operational costs of each layer would be paid for on an as-used basis by each department and treated as a true “aaS” model. However the setup of the original framework would need to be a corporate level budgetary item.
A rigid but minimal set of Architecture Principles would be required to :pilot” the selection of suitable applications for use in the MAP;
- Each Business Department (BD) is its own domain
- Each domain is responsible for entities that are intrinsically linked to that domain
- No BD may replicate data or have duplicate functionality of another department or outside its core domain, access to non domain entities must be done via the SOA layer
- Applications purchased or built must conform to the Security, Data Transfer, SOA and Rules/PE standards defined within the MAP.
- Extensions and enhancements to the MAP Backbone are the responsibility of the IT Department (e.g. a new service or rules-pattern is required)
- BD’s are technology agnostic in that they can choose the OS and languages they wish to use, however all costs related to these choices are borne directly by the BD.
- Only applications that are considered “componentised” and “domain focused” may be considered for purchase/build. No “Do-it-all” solutions are allowed
- No DW’s or Big Data solutions can be built within a business domain, this is a standalone BD and will be treated as such (Think of this as the “tender or committee boat” in a marina). Everyone has use of it but it is owned and managed by the marina
- There is no overall IT budget for applications (with exception of the MAP and Data Domain). Each department decides how much of its own budget it wants to spend on its own solutions. They must also fund the extensions to the MAP Backbone to facilitate these solutions
- The “you bought it” you “own it” principle is enforced. No centralised helpdesk or operations are available from IT.
So where does this leave the traditional IT department? The IT department transforms into a true “As A Service” provider for the MAP Backbone and a Consultancy Group for providing oversight and consultancy services for application selection and implementation. At no point is IT directly responsible for any of the applications purchased by the business units.
When I showed this idea to Grant his initial responses were;
- Plug and Play operating models are a desired direction
- The challenge isn’t whats described above but in the Data and Integration Services required that permit interoperability between the business application & lines of business usage
- Some corporations are aligned with the design outlined but do not realise it or understand how to utilise / enforce it
- The biggest challenge for an organisation is to build an effective EA Roadmap around the approach and then allow it to be enforced so that “tactical decisions” do not wreck to vision
- Also in the analogy presented, boats and yachts are self contained, but what if a boat suddenly relies on a second boat for fuel or they couldn’t refuel because all other craft had used up a scarce resource
The structure and focus of the IT Organisation would dramatically change and simplified to provide two broad functions to the organisation;
The first would focus on;
- Availability Management
- Security Monitoring
- MAP Backbone Support
- Infrastructure Management
In other words, they are a commodity service that provisions Keep the Lights On (KTLO) only. Obviously in a secure model to protect the marina and the yachts from
bad behaviours. This reduces IT to a Utility, like electricity – to be consumed and paid for as needed.
The second function of the new IT organisation would involve Internal Consultancy and Business Change helper function, outside of IT, that specialises in;
- Enterprise and Solution Architecture Advisory
- Innovation and PoC Advisory
The future of IT as a commodity is here now, the cloud providers are already there.
New ventures will rarely start with any on-premises IT.
The challenges with the MAP model come from data integrity, reconciliation and real business intelligence across disparate systems. This is a 20 year old problem
that IT has failed to find a good answer for: Back in 1970’s when systems moved
from single mainframe to multiple systems and client service solutions, gave birth
to the data reconciliation and consolidation problem: MI -> BI -> Predictive
Analytics; Database -> Data Mart -> EDW ->Data Lake; Predictably the most
expensive and most underwhelming solutions to the business problem. So a plug-in
Yacht for Reporting across the Marina is needed. Again, it shouldn’t be IT managed.
An enterprise analytics group should own this problem/solution domain.
This approach to IT by its very nature forces a change in the business operating model that seeks to free the constraints of the lack of quality & skills breadth of a single technology function. Embedding the skills in the line of business is crucial.
Project management of all projects should be rolled into a organisation focused PMO. All projects in the organisation regardless of deliverable or function should be driven by this organisation.
A Technology Committee should be formed and chaired by the CTO. Members of this committee are CTO, Chief IT Architect (CA), senior representative of each business department. All decisions to purchase a solution must be approved by this committee meaning it is up to a business department to convince other BD’s that its decisions are correct and will not jeopardise the business. The CTO and CA are not allowed to veto solution selections by BD’s but can raise concerns and alternatives for consideration.
Grant came up with a cool name for the approach “Software Defined Enterprise” … more about that in later posts.
Our intention over the coming months is to flesh out this concept over a series of blogs co-published on each of our blog and LinkedIn feeds. Each of the posts will deal with a specific aspect of implementing this type of architecture initiative for both business and technology perspectives.
Grant Matthews is an acknowledged thought leader in all things IT architecture focused, his profile on Linkedin is at https://www.linkedin.com/in/grantdouglasmatthews