Recently I have been involved with working as a
Technology Operations Architect for a banking customer.This work involved assisting with Oracle
product knowledge and reviewing the IT operational requirements being raised by
the customer.After reviewing the
customers requirements the next stage of the process was to perform a
product fit-gap analysis (product does it out the box, 'fit', product needs work
around, 'partial gap' or product has no capability today, 'full gap'.Finally each requirement was worked through to
agree high level solutions and a way forward for IT operations to function as
desired.
The challenge is not only trying to display to the customers what the products can do but also applying the experience of actual real use. To help avoid the difficulties of implementing and more importantly ongoing management.Obviously it is always better to learn off other people’s mistakes and positive experiences rather than take the same journey alone.Working for a vendor it allows us to bring this to the table which is our defrentiator.The use of ITIL standards over recent years where implemented correctly has also helped operations architecture significantly improve and I personally am a keen follower / promoter of this.
The goal in the requirements gathering is to capture what is really required to provide IT operations the ability to run the infrastructure / applications avoiding outage, increased costs, etc.What is the pain that in future the customer wants to avoid?I always believe that due to the nature of the different technology operations have to manage with versions, platforms etc it is really about KISS, (keep it simple stupid).
In the old days scripts would be written for everything as this guaranteed the stability, control and ownership.However there is a cost involved with maintaining that approach and moving it forward as technology required to support changes.The inherent danger is that this too becomes an unsupportable mess, creating a job for life for those who wrote the scripts.
A lot is pushed towards products to solve these issues and make life better, however these applications need to be treated as applications in their own right and require careful management.There is no silver bullet or product that just out the box switch it on and there is the answer.Unfortunately the configuration requirements of these products is not included in the total cost of ownership and often left aside. This leads to a poor product implementation and most probably an operations failure or rejection of the product.
To me the real answer is about those responsible for
support standing up with governance, standards and policy as a first step.After all when it goes wrong it is those support
people that are held accountable.It is about working out the right solution required to allow pro-active
administration and the cheaper / best way of identifying an issue before the
business does. Even so far as having the means to fix or prevent the bad things happening in
the first place. Sounds very simple, firstly work out the 'what' followed by looking at the how later in solution development.
The hardest aspect for the customer is in defining operational requirements, 'the what'. Below is a great link from the US government department of homeland security. It's where a customer or group has given serious thought about when it comes to dealing with vendors and how to shortcut the process to give good requirement definitions.
Homeland_Security_Operation_Requirements_definition.
Another trend worth researching which has quickly taken off is the development operations triangle and matrix.Above is a great pictorial representation of how the ideal solution is about IT operations getting in a sweet spot between what a solution is against the cost, effort and value associated to obtaining it.This is where as a solution it may be that a script is the way to go or a product or combination thereof.
In summary it is more important to define what needs to be there as a priority in operations and then to
work through how to provide expected solutions. From an experienced veteran of support even though the 'How' may have changed over time due to technology the basic needs of the 'what' from an operations perspective have not.