Author Archives: André Jacobucci

About André Jacobucci

Andre started in the IT industry in 1994, coming from an engineering education. After gaining experience in Application Development, Andre deployed ITSM solutions as part of major projects delivering ITIL-based Service Management capabilities. These projects took him to work in the USA, the Netherlands, Germany and Switzerland. Recognizing the key importance of people's knowledge, attitude and behaviour, Andre founded ILUMNA with Bruno Aguirre in 2003 to provide consultancy, training and certification services to the then initiating ITIL market in Brazil. Andre joined TCS UK as a Principal Consultant in 2012 and since then he has been delivering services in the practice of Service Integration and Management (SIAM).

Blending Old and New for a bright Agile future

Future And Past On Green Road Sign

Information technology is always evolving. Everyday old paradigms are challenged and, eventually, replaced by new ones. This is what makes the IT industry so interesting and so attracting to IT professionals. This also explains the abundance of job opportunities in the industry and a never ending demand for new practices and ways of working.

The pace of change requires experienced professionals to be open-minded to what is new and patient with the younger professionals, who bring in new enthusiasm and energy, but also a share of mistakes and shortfalls that have been repeated exhaustively in the past, but are brand new for them!

Very few question today the business value of Agile when developing new IT solutions and services. However, Agile is focused on doing things in a time-boxed manner and we know that some ideas require time to mature. So, there is always an element of risk in the Agile approach, that must be identified, understood and accepted by all involved parties.

The beauty of Agile is that the solution is not necessarily expected to have been thoroughly thought through by the time it “goes live”. However, this has consequences that should be understood.

One possible scenario is that the data produced by the solution can contain defects that are difficult to correct afterwards. This represents a type of technical debt that needs to be managed by the business as well as the teams that develop and support the solution.

There are cases where data correction can be done via smart algorithms. However, in others cases, a manual work-around (i.e. re-work) might be necessary. Even worst if help is required from end-users to address the shortfall.

In this example Agile can be seen to conflict with Lean. Lean is keen to do things right the first time and looks down on re-work as one of the worst forms of waste.

Is there a solution for that?

As usual, there is no silver bullet, but Design Thinking – a method for practical and creative solution of problems whose notions can be traced back to as early as the 1970s – resonates quite well with the Agile generation, and brings in hope by helping product owners to orchestrate the support of a multi-disciplinary team to help them defining and designing what needs to be developed, i.e. “the right thing to do”.

Agile ways of working are a must and there is no way back. Practice and observation have proven that Agile is the right way to do things. However, Design Thinking and Lean values need to co-exist along with Agile, as Agile alone might not be enough to identify the right things to do.

As for us, experienced IT professionals, we must keep our eyes wide open to new practices in our day-to-day jobs, even if those practices are not that much “new”. As for the younger generation, there is a wealth of experience out there, that can be wisely and energetically leveraged. The blend of tradition and revolution, old and new, seems to be the most appropriate combination to face the challenges of information technology in the next few years.


Agile Transformation: The Minimum Viable Operation (MVO)


As more and more organisations adopt Agile practices like Scrum to deliver complex projects, old traps and organisational challenges seem to get new clothes and terminology to doom these initiatives.

Enterprise IT, and IT professionals in general, have a reputation of being too product-centric.

Whilst Scrum is one of the best known manifestations of Agile principles and values, deserving the credit for fostering a collaborative and dynamic backdrop for IT and non-IT professionals to work together, it has a natural tendency to become product-centric.

The Minimum Viable Product (MVP) – a core concept in an Agile project – remains product-centric, regardless whether you replace the P of Product with the Ps of Processes, People and Partners.

The problem is amplified when the “product” is not aimed at external consumers, like the apps that you run in your smartphone, but at internal and external corporate stakeholders that will need to change their ways of working to use the new “product”.

Organisations rely on a complex interactions and workflows in order to operate. Large organisations go further and rely on defined processes to orchestrate these interactions. These processes are usually interdependent and managed by different areas.

Initiate a complex IT project in this scenario and give each process owner the hat of a Scrum “Product Owner” and the result is very likely to be the same as 30 years ago: each one will develop their own product, taking into considerations the needs and requirements of their own process silos, ignoring the inter-dependencies and the impacts on other areas.

Add a multi-supplier environment, where parts of the operation have been outsourced to external companies, ignore contracts and the enterprise is fully equipped go down its route to delays, additional costs or even complete failure.

The good news is that there is a way to avoid the trap and use the best of Agile and Scrum in a transformation program.

Think about the Minimum Viable Operation (MVO) that would allow the organisation to test new ideas, tools, ways of working, people, suppliers and partnerships. Think about the internal and external dependencies and try to identify that minimum set of Ps that would allow the organisation to go-live with the concept.

An example in the IT Service Management (ITSM) area, traditionally process-centric, may illustrate the concept.

IT Service Management Background

IT Service Management is based on a set of interdependent processes. Change Management, Configuration Management and Service Portfolio Management are three of the processes described in ITIL, the most well know framework of IT Service Management processes.

Whilst Service Portfolio Management look at how IT Services and resources enable the business from a strategy perspective, Change and Configuration look on a more granular and technical level, accounting for and protecting the specific components required to deliver those IT Services.

Configuration Management maintains a database, known as Configuration Management Database (CMDB), with information about those components and how they are related to the IT Services.

Change Management deals with many different types of change. These changes are categorised so that the most effective workflow can be selected. Regardless of their type, all changes are recorded and assessed with regards to the exact components that need to be changed, and potential impacts to other components and services that rely on those components.

The integration and inter-dependencies between Change, Configuration and Service Portfolio Management becomes clear during change approval. At this point of the Change Management process, it is not possible to make an informed decision unless there is information regarding the components being changed (as informed by Configuration Management) and the impacted services (from Service Portfolio Management).

This shows how Change Management is dependent on CMDB and Service Portfolio information.


Suppose a large organisation wants to transform its IT Service Management practices to boost agility in Enterprise IT and decides to start with Change Management as there is an internal perception that the process is bureaucratic and is hindering agility. Suppose the transformation program includes adopting a new IT Service Management tool and re-designing other processes, apart from Change Management itself.

The organisation decides to adopt an Agile Transformation approach, based on a roadmap. The roadmap establishes three releases, with the first one delivering the Minimum Viable Operation (MVO) for the new Change Management.

The MVO for Change Management (mvCHG) should be defined in terms of:

  • the Minimum Viable Process (mvProc): a self-contained sub-set of Change Management activities;
  • the Minimum Viable Product (the traditional MVP): the minimum set of functionalities required from the tool to support those activities;
  • the Minimum Viable CMDB (mvCMDB) and the Minimum Viable Service Portfolio (mvSP): representing the minimum set of data and information required for the process to work;
  • the Minimum Viable Resources (mvR): as the minimum set of internal and supplier resources and services to perform the required activities, according with the new roles and responsibilities.

After some consideration, the organisation decides to define mvCHG around the Standard changes, as these are low risk, low impact, repeatable changes.

Because Change Management is dependent on the data from the CMDB and the Service Portfolio, the mvSP is defined as only those services for which there are standard changes, and the mvCMDB is defined as containing only the Configuration Items (CIs) associated with the Standard changes.

The mvR identifies the teams and suppliers involved in delivering Standard changes, which also helps to determine if contractual changes are required to support the MVO.

The MVP identifies the minimum features required to support the operation of Standard changes, like  to be able to select a Standard changes from a catalogue.

For the second release, the organisation decides to expand the operation to all patching changes, which requires the CMDB to be populated with all CIs that require patching.

For the third and last release, the organisation decides to operate all other types of change, including Normal and Emergency changes.


Enterprises don’t want do adopt Agile development, they want to become agile themselves. This is achieved by adopting Agile values and principles in all business functions, not only IT. Agile values and principles, supported by agile practices, lead to agile decisions and actions.

The Current Operation can be transformed into an Agile Operation though an Agile Transformation.

An Agile Transformation gives an organisation the opportunity to experience Agile values and principles during the transformation journey itself, preparing them to become agile.

Scrum is traditionally used to develop “products” such as software and process documentation. However, Scrum can also be used to deliver transformation.

It is possible to avoid the natural tendency of Agile Development to become product-centric and the natural tendency of IT Service Management to become process-centric.

The MVO allows an organisation to experience new practices, tools, partnerships and ideas as a complete and integrated system, whilst considering all aspects of the operation – not only the Product – and laying solid foundations for future expansions of scope and business value.

Rethink Change Management in an Agile and DevOps Era

the-eleventh-hour-1364076_960_720Change Management is probably one of the most unloved IT process. Often seen as bureaucratic, arbitrary and a waste of time, it is also one of the most difficult processes to get right.

Those who have read the initial chapters of “The Phoenix Project” novel will appreciate the fact that, when things go wrong – and sometimes things can go terribly wrong! – the first question people usually raise is “what has changed?”.

If support teams do not have records to tell them what has changed, it is likely that they will need to spend extra time trying to find out the answer before they are able to tackle an issue or address a service outage.

Hence, the benefits of Change Management cannot be measured in itself, but on the positive effects it causes on other areas of the Business and IT.

The fact is that IT people are keen to try out new technologies and configurations and the beauty of many business innovations derive exactly from this constant technical curiosity.

On the other hand, the IT environment is usually complex, interconnected and extremely sensitive. In the IT world, replacing a comma with a dot is all that it takes to cause a system to fail, which makes IT changes quite scary.

In large and complex environments, it is unlikely to find a professional with expertise in all technologies and applications. Hence, depending on a single person to make a decision regarding a change is as risky for that person as it is for the business. High risk changes should be discussed by the Change Advisory Board so that it can be assessed from different perspectives, and the decision, whichever it might be, is shared across all members of the CAB.

Being a control process, Change Management has a natural tendency to become a boring tick box exercise. There are many reasons for this:

  • The process needs to operate within agreed rules, which are usually defined in process documentation. However, once the rules are set and people get used to the process activities, it is easy to forget the reason why these rules and activities were established in the first place;
  • Considering that the process is repetitive and makes the IT environment more stable and reliable over time, people may get a false sense of security and forget that the reason the environment is stable and reliable is because changes are deployed in a controlled manner!;
  • New technology and automation can produce the same or better results than a manual Change Management process. However, these technologies may not be broadly available or may not be applicable to all IT environments, requiring organizations to maintain manual tasks;
  • Service Management tools may not be flexible enough to enable a smooth evolution of Change Management practices, sometims requiring costly customisation and forcing practitioners to follow obsolete ways of working.

It is vital that Change Management practitioners secure part of their bandwidth to question whether their current working practices are still applicable and look for opportunities of improvements both within and outside the organisation they work for. Looking for better practices should be an ongoing activity embedded in a good Change Management setup.

As far as efficiency is concerned, several mechanisms can be put in place in order to streamline Change Management. Some of the most common are:

  • Classifying services and applications according to their importance to the business: This helps Change Management to decide how much effort should be spent on assessing the change and defining the right level of approval required;
  • Creating change models: This consists in developing standard plans for testing, planning and implementing specific types of change. Apart from boosting standardisation and repeatability, these models enable reduction of turn-around times, increased efficiency and highlights the fact that the type of change that being proposed is as important as the service or application that is being changed. This prevents minor changes to business critical services and applications to follow the same costly and lengthy process that a major change would genuinely require;
  • Facilitating change approval by leveraging CMDB information: This consists in dynamically defining change approvers based on the affected CIs, and chasing these approvals automatically. This can be used as an alternative to a meeting to discuss and approve the change.

An area that may become a conflict zone if overlooked is the integration between Change and Configuration Management. Although it might be obvious that a good working relationship between Change Management and Configuration Management is mutually beneficial – on one side Change Management depends on accurate and up-to-date information about the IT landscape in order to perform a reliable impact assessment and ensure changes are approved by the right people, on the other, Change Management can help Configuration Management to identify out-of-date information, trigger actions to get the CMDB updated and monitor unauthorised changes to CI records – defining the correct scope and level for the Configuration Management System is still a challenge, particularly when the exercise is carried out in isolation.

There is clearly a difference between the information required for Systems Management and the information required for Service Management. Technical attributes that are essential for Systems Management are irrelevant for Service Management and vice-versa. Although technical attributes can automatically captured via discovery agents, Service Management attributes like owner, support group and approval group are likely to require some level of manual intervention. The mix of automated and manual updates to the CMDB can create tensions between Change and Configuration Management. The good news is that these tensions can be addressed by frequent connects between practitioners, continual learning and improvement.

Agile and DevOps approaches will also require a major mind set upgrade as far as change approvals are concerned. Change Management has historically focused on protecting the live environment by carefully assessing the best way and time to deploy the change into production and ensuring all stakeholders are happy with the approach. However, in an Agile and DevOps environment the question shifts from when or how to deploy a change to why to do the change in the first place. Addressing this new context entails answering questions like “how this change will improve the business?”, “what is the risk of not doing the change at all?”. This is a shift from “Approval to Deploy” to “Approval to Build” and requires a much more thoughtful and business oriented approach for Change Management. Apart from protecting the live environment, stakeholders will expect Change Management to protect the business from ill conceived changes that do not add value. In this new scenario, once a change is approved, its orderly and controlled progress throughout its lifecycle of build-test-deploy should work like a clockwork, and be automated as much as possible.

Automation will become mandatory. Risk assessment, identification of affected Configuration Items, identification of change collision, adherence to release and maintenance windows, approvals, communication and task management are a few examples of Change Management aspects that will require automated approaches to enable change owners to focus on what is really relevant: the value of the change to the business.

This is a new and exciting era for Change Management, which will require us to rethink the process and look for innovative ways of working to fulfil the new business mandate.


Take away:

  • Change management is there to protect business and people from their own mistakes
  • It is possible to avoid Change Management to become a hurdle for business innovation and a boring tick box exercise
  • Change and configuration can and need to have a happy marriage
  • Moving from Approval to Deploy to Approval to Build will require a mind set upgrade
  • Survival kit: Automation, Automation, Automation

ITIL and ITSM in Multi Modal Application Development World

The ITIL framework and the IT Service Management practices have expanded beyond service desk and IT operations a long time ago. ITIL V3 (2007) brought visibility to the full lifecycle of a service, talking about strategy, design and transition of services much before they become operational.

Sadly, a good amount of people did not get it and also did not realize that the technical solution, which includes the application and all the underlying technical infrastructure required to host and manage it, is part of the service. As a consequence, they do not realise that designing and developing an application is part of designing and developing a service and defining the development methodology is part of defining how the service will be managed throughout its lifecycle.

Putting it in different words, these people think that ITIL and IT Service Management are constrained to IT operations and supporting services. They do not recognise the full lifecycle of a service and, therefore, do not recognise that the real scope and applicability of ITIL and IT Service Management practices include design and development.

As far as development methodologies are concerned, Agile and Waterfall can and should be used side by side and collaboratively. I suppose that after wasting millions in failed Agile projects, some organisations will realize that both methodologies have their applicability and the decision to use one or another should be based on a good understanding of the specific circumstances and the pros and cons of each methodology. As these methodologies also represent different ways by which an IT organisation (service provider) engages and interacts with its clients (business areas), more mature IT organisations will develop both capabilities and will invite business stakeholders to participate on the decision taking.

As far as service management framework and high level practices are concerned, an incident will require a quick fix and a problem will require root cause analysis, regardless of who does it and how fast it needs to be done. Changes and new features will still need to be tested before deployed and released, regardless of its size and whether test is manual or automated. Risk will still require to be managed accordingly with its impact and likelihood.

We should avoid to think that universally desirable characteristics and behaviours – such as automation and collaboration between application development and IT operations teams – are exclusive of the latest IT movements, e.g. DevOps. These things have always been part of good service management culture.

We should also avoid to think that virtue is in the extremes. Extremes may be useful to help us understand present contexts and new concepts. But adopting them as targets is not only unwise, it is a sure recipe to keep spending millions in failed IT projects.

Don’t forget commercials!

terms smallThe Quick guide to SIAM by Jan Vromant succeeds in highlighting the importance of the commercial component in a SIAM structure, giving it a separate box in his proposed framework.

Here are some additional considerations that have a big impact on how well SIAM can operate and ultimately deliver business value:

  • Contracts and agreements need to be carefully designed, reviewed       and managed to enable not only integration and interoperability between multiple suppliers, but the correct behaviour and attitude;
  • Non-Disclosure Agreement (NDA) clauses require particular consideration as they may hinder the flow of essential information between the client, the SIAM function and the multiple suppliers;
  • Service definitions must be consistent across all contracts and agreements and be associated to an overall operating model that clearly articulates the role of SIAM and each supplier;
  • If the SIAM function is outsourced, its service provider is likely to require to be assigned as managing agent of the client.

Searching for the right piece

right piece“Assemblying the Jigsaw” is the name of a whitepaper published by ISG in 2013 about the need and the role of Service Integration and Management (SIAM) in multisourced IT environments. The article, which is still available here, provides good guidance regarding success factors and implementation challenges. My experience has also shown that finding the right SIAM model is also essential and tuning it may take a few iterations. There are several alternative SIAM models (internal x external, independent service provider x lead service provider, etc.) and the speed of implementation needs to match the level of maturity of the organisation and the time required to manage the organisational change.

Combining SIAM and DevOps for Digital Reimagination

CEOs are under increasing pressure to move their business into the digital world, reimagining the business model to take advantage of the Social, Mobile, Analytics and Cloud (SMAC) digital forces that are redefining the way organisations interact with their customers. They also expect CIOs to act as a business leader, taking a business-focused approach to leading the IT function and contributing to issues and subjects beyond technology.

The challenge requires not only leveraging new technology, but new ways of working within the IT function and new sourcing strategies.

This has led to an increasing interest and relevance of DevOps and Service Integration and Management (SIAM) in recent years.

Whilst DevOps recognises the importance of integrating development, quality assurance and operations into a seamless mechanism to deploy faster and more reliable software solutions and services, SIAM is the response to IT organisations that seek to rip the benefits of a multi-vendor environment, integrating services sourced from carefully selected IT providers.

But would SIAM and DevOps work together?

To answer this question, let’s take a further look at the key drives and characteristics of each of these approaches.

DevOps emerged from a group of professionals dissatisfied with the results of the silo behaviour that arises from the way roles and responsibilities are traditionally split between development, test and operations teams. Project delays, unreliable solutions and services, high defect rates in production, lack of flexibility, low performance and high cost are amongst the issues that DevOps wants to address.

The most important characteristics of DevOps are the understanding of the business behind IT, the change in attitude in the IT professionals and the use of technology to automate service operations and the develop-test-deploy model.

The change in attitude refers to the way the different IT teams engage, interact and see each other. Most organisations have already realised that trust, integration and understanding of the business do not happen naturally. They need to be fostered and continuously nurtured.

Some critics of DevOps argue it is just an excuse to combine distinct and specialised roles into the same person. It is important to note that, although in small organisations the same person may need to perform all roles, the DevOps principles are also applicable to medium and large size organisations.

On a different perspective, Service Integration and Management (SIAM) emerged from an increasing number of companies opting for an increasing number of IT service providers, to improve cost transparency, reduce risk and take advantage of best of breed solutions and services.

Although not immediately evident, the issues that rise from a multi-sourced environment are now encouraging clients to place increasing importance on the SIAM role.

SIAM aims to address issues such as contractual gaps and overlaps, broken processes and communication channels, conflicting interests and performance targets, distinct governance mechanisms and the lack of end-to-end service ownership that ultimately lead to value leakage and customer dissatisfaction.

The UK government has also adhered to the trend, having included a guidance on SIAM to chief technology officers.

Some of the most important aspects of the SIAM role are the coordination of people, processes, technology and data, and the governance across multiple suppliers, to ensure effective and efficient operations of the end-to-end service delivery to the business user.

DevOps and SIAM converge in addressing current business and IT challenges and targeting people and attitude as primary drivers of performance and value. Whilst DevOps addresses the cons of functional specialisation and the spread of responsibilities across different IT teams, SIAM deals with the additional challenge of spreading services across multiple vendors.

DevOps bring fresh air and enthusiasm to build more dynamic, collaborative and intelligent ways of working, leveraging peoples knowledge and the use of technology to automate routine tasks.

SIAM complements DevOps bringing in Service Management and Contract Management capabilities.

Recent SIAM implementations take advantage of the full service lifecycle approach introduced by ITIL 2007/2011, replacing the traditional support-centric approach of previous implementations.

They also use ITIL and Enterprise Architecture concepts to ensure there is no ambiguity in the definition of service elements, so that a robust and comprehensive framework of contracts, agreements and governance mechanisms can be put in place to clearly link each service element to the vendor that owns it.

SIAM and DevOps are thus two sides of one coin. Combined they can bring in the benefits of innovation, collaboration and best-of-breed sourcing required by CEOs to realise their digital business strategies, and by CIOs to reimagine the IT function beyond the traditional technology perspectives, improving value and customer experience whilst reducing time-to-market and operational costs.

salt and pepper smallSIAM and DevOps are like salt and pepper: they are different things that work very well together.