IT and Digital's New World Order

A common theme in many IT departments or functions is the "Them and Us" relationship with the rest of "The Business". Miles of column print are given in IT publications and by analysts on emotional hand wringing about the lack of connection with colleagues in the business and multiple surveys examine the CIO's role and status in the business as well as his or her relationship with the CEO.

Recently, however, the press has been distracted by the idea of automation and everyone being replaced by AI based automation and the supposed death of many jobs, without actually bothering to analyse the capability of AI tools. the fact is that they are both powerful and limited at the same time and it takes an aweful lot of training to get some quite basic capability out of a machine learning application. Anyone who has used Alexa (Amazon's voice based AI agent for automating your home, answering general knowledge questions and playing music) knows that you can be both delighted and frustrated by her abilities to do what you want or to get it so completely wrong that you wring your hands in despair.

In reality the things having the most impact in the UK are Brexit (because it is used as a general excuse for not making decisions and refusing to hire new staff) and the impact of XaaS and Lean. These are gradually evolving the way in which products are developed and IT works both within itself and with other people in the wider business. It's no longer appropriate to organise IT around functional siloes and gatekeeper roles, which slow down progress and frustrate our business colleagues. The move to end-to-end product teams and more integrative roles means that IT needs to shift its mentality from reclusive castle dwellers to engaged collaborators, as IT becomes a fundamental part of business operations. The rest of the business has to do this too. Because, when you look at it, most other functions suffer similar problems of angst and feelings of under appreciation.

The most difficult part of the evolving role, is how does IT relate to Business Operations once this transition has been made and IT is properly organised to align and integrate with Operations. This means that many traditional assumptions around how to implement ITIL, organise testing or approach enterprise architecture (for example) need to be revisited. People in IT need to move towards taking more interest in the business and its customers, as well as what a collaborative culture looks like. It also means that CIOs need to become more assertive (not aggressive) in engaging with their peers to understand and agree business priorities, as well as partnering internally and externally to move quicker to address urgent needs. Old ideas like "boiling the ocean" with monolithic technology change initiatives need to go. Smaller, quicker steps and daring to experiment is now the order of the day. Whilst, rigorously pursuing simplification, security hardening and IT automation in localised areas as these steps are taken is the path to earlier value delivery. This means that 2 speed IT is a misnomer, its more like 6 gear 4 wheel drive IT, which adapts to different terrain and problems.  

Group Technology For DevOps

One of the often overlooked concepts absorbed by the umbrella term of Lean is Group Technology. The concept originated in Russia, was refined in the UK and then seized upon by North America in the 1960-1980s period, especially when robot cells and flexible manufacturing were the fashion in Manufacturing Systems.

Basically the concep was simple. Old fashioned manufacturing factories used to be laid out in "functional" organisations. So, say, all the Lathes were in one corner, the drilling machines would be in another part of the factory and the milling machines in a different part or even a different building.

A component might require that: 

1. bar metal was cut to size - done by the sawing section;
2. it was turned to shape - done by the lathes section;
3. some holes were drilled - done by the drilling section;
4. a flat surface was milled on one side - done by the milling section;
5. one end was polished extra smoothly - done by the grinding section;
6. before final inspection, packing and shipping.

Each step would be conducted under the aegis of a different foreman. Each foreman had his own priorities and was tasked with running his section efficiently. At each step, the appropriate machine would have to be set up, perhaps with a special jig as well as, with its specific set of cutting tools.

So the process was a long series of queues and delays for set up, with only a small portion of time spent actually cutting metal. Efficiency was assure by having as much work as possible queued at each section, so the machinists never ran out of work.

Process times were long, delivery dates were never guaranteed to meet promised delivery dates, but it appeared efficient, even if  lots of money (working capital) was tied up in work-in-progress inventory. It was great for the foremen, because they were never individually to blame if something was late.

Group technology, was originally focused on reducing setup times. It involved using a classification system to identify parts which were similar to manufacture, e.g. small long thin round round parts or large short squarish parts, and batching them together for manufacture at the same time.

Then the idea of the group technology cell was introduced. All the machine required to make small round parts were organised into one part of the factory, in the normal sequence in which they might be used, creating a flow line. So similar parts were all sent to the same cell and put under the control of a single foreman who was also responsible for delivery performance. This allowed parts to be batched and pipelined along the natural flow line to meet both effectiveness and efficiency needs. It also meant that there was only one queue, the one going into the cell and work in progress could be reduced. Adding TQM techniques into the mix, so that the foreman was responsible for quality as well, turned him into a mini production manager and enabled quality to be improved. Then, where practicable, automation was introduced to raise overall performance further.

So what does this mean to IT operations. Well most organisations have normally organised so that the unix/linux administrators sit in one corner reporting to a senior administrator. The NT administrators sit in another corner with their senior administrator. PC administration sits under desktop support. DBAs sit in their own little getto, with a senior DBA. The network administration people might be in another building. If global outsourcers are involved, then corners become "Competency Centres" often geographically dispersed.

In traditional "on premise" or "in data centre" operations, a large part of the time of administrators is focused on the box shifting aspects of the role with manual administration of builds and maintenance tasks. No one team is responsible for the support of an application. So when things go wrong, different disciplines point the finger at each other, saying "our bit works it must be theirs which has gone wrong". This makes reacting to incidents slow and innefficient, and slows down releases of new features. So what appears efficient is an inhibitor on value by slowing change and reducing uptime..

Modern "Everything as a Service" (XaaS) environments offer new opportunities. The job can be refocussed from box shifting and manual "oiling and adjusting" type tasks to a higher level of "End-to-End" application administration. This requires administrators to be re-organised into either application facing (if it's large like an ERP or core banking system) or business facing (if there are lots of linked smaller applications used by a business area) teams. They can then work with application and business facing development and test teams to meet the continuous delivery needs of modern digital products and applications. Tooling such as Splunk or Oracle's Management as a Service are good at pinpointing root causes of problems, ensuring that the team tracks down causes quickly and focuses on jointly fixing issues. 

That way, accountability lies with the team and incidents can be resolved quickly, whilst new releases are jointly planned to optimise value to the business. This is Group Technology for DevOps.

Post Digital Outsourcing - Going for Value

One of the things which always has frustrated me when dealing with traditional outsourcing companies has been the huge gulf between the Sales Proposition and the Reality of Day-to-Day Service.

Companies usually think they are going to buy the best skills in the market and get access to superlative service from a transformational partner who delivers agility and control, so they can forget about the complexities of running IT. In reality they get bland, slow moving and unimaginative bottom up services which are slow and expensive to change. Where people have looked for partnership, this has usually failed to materialise as relationships descend into "Robust User-Supplier Conflict" (or RUSC). In fact the traditional model has been an anti pattern to progressiveness and this has only been made worse by offshoring to Asia, where extreme cultural differences and expectations have only made things worse.

As I mentioned in a previous blog, The Death of Outsourcing, this model is no longer sustainable in the light of all things digital. So what can a Post Digital Service Provider offer now that XaaS threatens to steal outsourcing's breakfast?

The reality is that, whilst XaaS does a lot to free an enterprise from the Tyrrany of Infrastructure, XaaS introduces new complications as the overall technical environment is much more complex; Digital also means that enterprises need to learn to move quicker with disciplined lean practices that enable continuous change. New IoT based models also bring new challenges of scale.

So the new breed of Digital Service Partner needs to position itself to avoid RUSC and focus on Assured Value, Integration and Speed. Where: 

• Assurance covers secure and consistent delivery of change and operations;
• Value focuses on user and customer experience, insight and the right quality at an affordable price;
• Integration deals with the complexity of identity and integrating multiple sources of XaaS services as well as working with multiple SI partners and in-house development teams to deliver joined up services;
• Speed addresses agility, continuous change, innovation and responsiveness to changing business and technical opportunities and risks.

Such services are likely to include 3 key elements:

1. a Foundational Use of IT Access Service - everything needed to deliver a user device centric service, e.g. smart phone, pad, laptop and supporting network, gateway, office automation software, storage, print, peripherals and anti malware based services.
2. a Service Integration And Application Management Service (SIAM) - which integrates and delivers services on a Hybrid Cloud basis. This is likely to include Architecture Management (AMO), Programme Management (PMO), Service Delivery (SMO), and Security Operations (SOC and Security Operational Processes), as well as Activity Based Costing (along TBM or OBASHI lines).
3. a Lean System Integration Service - which can provide specialist development and implementation skills, but also embraces partnering with internal and 3rd party partners and provides support for the full range of Agile and DevOps processes needed to deliver continuous change.

Naturally there will be other more specialist services which may come too, e.g. computer forensics and advanced threat intelligence, Fleet Management for IoT devices, or managing innovation communities as innovation goes social. But these will be value adds building on a core foundation.

GDPR, CIO issues, Lean Data & Data Portfolio Management

Last night's CIO event hosted by Harvey Nash and KPMG was held to launch their 2017 CIO Survey "Navigating Uncertainty".

In the Panel discussion afterwards, one of the key issues raised was about "knowing where your data is". GDPR is certainly driving this, for personal data in Europe and anyone who trades with organisations or consumers based there. As its difficult to implement the "right to be forgotten" if you don't know what data you hold and where it is. Similarly, SoX in the US has driven similar concerns about Financial data. The move to "Cloud First" also compounds this need, as it is core to successful integration.

So why is this such a big deal as much of GDPR is about doing things which a business really ought to be doing anyway? basically its ancient history. Most large organisations have grown partially by merging with and acquiring other organisations. Their management teams often have the tendency to declare victory before full integration occurs.

Then there are cost cutting issues. Most businesses have been through boom and bust cycles of  large investment followed by cost cutting and asset squeezing. Often this has included head count reductions or outsourcing. Each of which ensures that knowledge about where things are leaves the organisation. Many service providers tend not to document things well, if they are allowed to get away with it, as this helps keep effort and FTE (therefore costs) down. There is natural staff churn of anywhere between 5% and 20% per year in typical companies, depending upon culture, rates of pay and opportunities. Documentation does not keep pace with lost knowledge as exit processes are usually poor in knowledge transfer.

Finally, DIY activities in the business often results in unofficial applications being adopted, especially as XaaS makes this easy to do. So put this all together and it is little wonder that organisations often do not know where their data is or even what data they have. This is a situation which brings inherent risk. If an organisation does not know where its data is, how does it protect it. If no one knows what data is help and "managed", then how is it integrated, kept coherent, kept clean and timely? how does the organisation know what it is actually spending on data or even what the value of its data is. Then there is the small matter of compliance. How does the organisation know whether it is complying. These are all data hygiene issues which need to be addressed if digitisation is going to support a Digital Business Model.

So now is the time to introduce Lean Data and make sure that Data Portfolio Management (DPM) is practiced as part of any approach to Asset Portfolio Management. (Asset Portfolio Management = Application Portfolio Management + Infrastructure Portfolio Management + Data Portfolio Management).

Lean Data principles mean that:

• Organisations know what data they hold and manage;
• Data is classified according to subject area and criticality;
• Only the minimum data necessary to Add Value to the business is held;
• Data replication is kept to the minimum level necessary to optimise business performance;
• Data Value is determined by its utility in Serving the Customer, Supporting Essential Capability, Protecting the Organisation, Providing Insight for Business Decision Making.

Data Portfolio Management is concerned with:

• Knowing what data is held and where it is;
• Understanding the quality of the data;
• Knowing what technology is used to manage the data and its overall condition;
• Being able to address questions concerning issues such as criticality, protection, archiving, cost of management;
• Understanding how Master Data Management (MDM) and integration occurs;
• Knowing who has Stewardship responsibility and consumer rights for the data;
• Regularly reviewing management actions to improve Data Value and address Lean Data principles.

Are You Ready for Digital Disaster?

We all know that we should have a Disaster Recovery / Business Continuity Plan. Yet most of us have worked in businesses where this is a convenient afterthought. Even when businesses have them, active testing of them is often patchy at best. Many businesses aspire to do this at least once a year, fail to meet this target and even if they do, they then brush a lot of things under the carpet.

For many years the key concern has been a major fire, followed by lesser concerns about flooding, terrorist attacks and other major natural disasters. Statistics suggest, that in the UK the typical rate of major fires is around once per hundred years of a data centre's operations. This is actually a very high high rate. Although in actual practice the more frequent major incidents which disrupt operations tend to be caused by more mundane things such as loss of power from the grid, major network switch failures within the the data centre or loss of telecommunications coming into a data centre.

Many businesses have been content to make minimal investment in preparations and accept the risk. They have mostly got away with this despite urban myths about the high percentage of businesses, suffering major incidents, which go out of business. Though if you personally have ever lived through such an incident, you would not want to do so again.

This complacency is looking increasingly out of place as enterprises go digital. For one thing, operations become impossible to deliver with failure, for another the increasing frequency of "Cyber Attacks" means that the old cosy assumptions are no longer valid and not only may operations be disrupted but valuable information or IPR stolen and an enterprise's reputation destroyed along with customer confidence.

The increasing pace of change inherent with modern digital business, based on Agile and DevOps styles of continuous change, also mean that an annual test is laughable as recovery plans will never be up to date if annual refresh thinking continues to dominate. This will also exacerbated by use of multiple SaaS, PaaS and IaaS services. As although each one used may increase the theoretical resilience of the enterprise's systems, it also complicates the inter-dependencies between them.

Business and IT Management Teams need to actively engage in preparing for major disasters and incidents. This means several things need to be addressed:

- capturing all changes to the systems and process lanscape, especially adoption of SaaS services, so that current architecture is documented, understood, risk assessed and continuously revised in recovery plans;
- regular incremental testing of recovery plans to address changes to the systems landscape;
- conduct of scenario "war games" to evaluate responses to different types of threat, taking into account that under Murphy's Law key people may be unavailable when a major incident occurs;
- regular review of major 3rd party services that the enterprise relies upon for the suitability their response capabilities and likely behaviours;
- media training of all senior executives and managers who may be called upon to represent the enterprise in the event of an incident, taking into account that some of them may have been incapacitated by the incident or away from the business.

Not many of us work in enterprises where all this happens, but most of us need this now.

The End of Outsourcing?

Most of us who have been in the trenches dealing with Outsourcing Partners in the last few years are puzzling over where it all is going. 3 major forces are changing the current model as we know it:

(A) Exhaustion of the Indian (or Off-Shore Labour Arbotrage) Value Proposition;
(B) The move to Everything as a Service (XaaS) as new players offer different types of service;
(C) The death of Monolithic Service contracts, as enterprises pursue increasingly complex Multi-sourcing models.

The original attraction of the Indian model was access to a large pool of well qualified talent which was artificially cheap as a consequence of exchange rate differences. As the offshoring model was pursued, the "Unseen Hand of the Market" has moved to erode the price benefits through year-on-year wage inflation and adverse currency movements. Additionally, as demand has risen, the talent has "followed the money" impatiently pursuing promotions, increased status and the opportunity to only work with the latest technology. This has led to unfettered job hopping, resulting in the loss of knowledge and the failure of individuals to develop deep experience. This has eroded the value proposition around talent. On top of this long distance relationships carry a heavy overhead in building them up and maintaining them, and the off shore players have developed business models and practices which assume that demand will continue to build at the same aggressive rate as previously. Many enterprises are actively taking things back on shore or in house.

The move to XaaS means that many of the traditional "box shifting and box running" services which were foundational to classic outsourcing are redundant. The traditional outsourcing players are losing the core "economy of scale" type services which they used to provide to IaaS and PaaS providers. Further more, the opportunities around traditional application based services are being eroded by SaaS providers. So although there are some niche opportunities where things like European data protection legislation or defence contracting requirements offer some opportunities, most of the market is moving to platforms such as those offered by Amazon and Microsoft. 

The continuous move to multi-sourcing started in the late 90s and has gradually built up steam over the last 20 years, especially as XaaS is now becoming the norm. This should also offer opportunity to move up the food chain to offer more value added services around Service Integration. Yet there is little evidence that any of the main outsourcing giants understand Service Integration or that there is appetite within customers to pay for it.

When I look at it, even in the area of Cyber where Security Operating Centre (SOC) services are in increasing demand, it seems that new entrants from the Aerospace and Defence industry have recognised and pursued the opportunities more aggressively, building both technical capability and market credibility.

So if you are looking at your service and sourcing strategy, it's time to think about what your model is, what kind of suppliers you need and to quiz them on their vision and direction. Otherwise you may be lumbered with a failing partner.