Articles

2017 may go down as the year of ransomware, rogue software that infects a computer, scrambles the data, demands you pay money to get access back, and eventually destroys your files. In May the WannaCry ransomware cyberattack affected more than 200,000 users in over 150 countries and disrupted operations for numerous corporations. This was followed in June by a new variant of the Petya ransomware, with this cyberattack impacting over 12,000 devices in around 65 countries, along with some high profile corporations. While most ransomware still targets consumers, what is notable for business architects is that according to Kaspersky Lab, ransomware attacks on businesses increased 11x in 2016. So what is the role of a business architect regarding cybersecurity, disaster recovery, and business continuity planning? I honestly have no idea. In the spirit of never letting a serious crisis go to waste, let's see how we can help.

Cybersecurity Framework

In the last twenty years we have become very good at mapping and improving processes; but we still have poorly structured organizations. Can we use our understanding of processes to improve organization design?

A process exists to deliver a positive outcome to a customer or beneficiary. Sometimes the beneficiary is the person who does the work, as when you make a cup of coffee for yourself. But most processes in organizations exist to do something of value for an external or internal customer, who is not the person doing the work. This principle, deliver value to the customer, lies behind one of the great developments in process work – Lean. By analysing a process with a focus on what is needed to deliver value to the customer and eliminating everything that is not needed, a process becomes Lean. But Lean tells us little about how the work and people involved in delivering the process should be structured into an organization.

So let me try to make a connection.

A SIPOC diagram represents a high-level view of a process. It shows the Suppliers, Inputs, Process, Outputs and Customers. The SIPOC Diagram plays an important role in Process Definition/Improvement and should ideally be done first before embarking on extensive process mapping. An analyst – in collaboration with other stakeholders – may use it to arrive at a consensus on the process before moving to a greater level of detail. To emphasize putting the needs of the customer foremost, the tool is sometimes called COPIS and the process information is filled in starting with the customer and working upstream to the supplier. It is very helpful to give people who are unfamiliar with a process a high-level overview.

Under what scenarios might you use a SIPOC diagram?

 The "Kid in a Candy Store" Product Owner and the "See Saw" Product Owner

This is the second of two articles that address the specific challenges you may be facing in your work with Product Owners. The first article focused on two very different types of Product Owners: The "Big Picture Thinker" and the "Aspiring Developer". In this article, the focus is on two types of Product Owners that appear to be different on the surface but who create surprisingly similar challenges for the Agile team: The "Kid in a Candy Store" Product Owner and the "See Saw" Product Owner.