Engineered, Integrated, Consolidated, Appliance ..... all of these (and more) are used to describe a new way of delivering IT functionality. Yes, I do work for the premier vendor of these systems but regardless of any particular vendors offering, there are implications that to some degree are common to all.
How do these systems fit into the existing IT landscape and traditional IT job roles ?
This very subject started a debate in our team in response to a request for a particular customer situation and got a couple of us thinking about this.
Friend and respected colleague @Zalez blogged about the changing job roles, the concept of DevOps and begins to shed light on the impact these new systems will have on job roles.
These sort of changes in roles are not only driven by vendors supplying IT capability in a different, more packaged format, but driven by how to adopt them into enterprise IT. See this article for some insights into Rogue IT and the need to embrace it.
It is my personal opinion that any IT department must have some sort of an architecture strategy to be successful in delivering what the business needs. I don't really care what it is called, Enterprise Architecture, Strategy, default vendor choice, etc, etc ..... the important thing is that there is some rationale behind choices being made. Only by having some idea of the structure and shape of existing IT will the effect of these new systems be able to be quantified.
From an Enterprise Architecture point of view it means a couple of things. Firstly, it means bigger, more course grained solution building blocks. Secondly, it starts to challenge the utopian view that Architects like to adopt of an organized, standardized layered approach and move to a more vertical, capability focused and interconnected fabric. Please not that this does NOT mean a return to Silo'd and disconnected. This drives true rogue IT.
By driving this change, the role of say, the Storage Admin for example, now has to start dealing with multiple storage technologies. Some of these may be focused on delivering eye-watering database performance for a Data warehouses and others delivering a cost effective, flexible Dev/Test cloud. The practical reality of this is that the storage for the DW will be under the direct, day to day control of the DBA's.
This shifts the focus of the Storage Admin role will become more of defining policy, strategy and governance across the storage landscape. Similar in concept to the impact that BPM has had on development roles in using tools to design new business capabilities by combine services into new processes rather than cutting code. It's just starting to happen further down the IT "stack".
Any (sensible) thoughts, comments welcome as I am currently working on how this approach changes Enterprise Architecture thinking and delivery.