Is this Bespoke Spoken For?

Posted on January 28, 2018 by Frank SAPAA

It is a truism to say that organizations, in particular governments, are relying more and more on technology to operate and deliver services. In a 2014 blog, IM/IT Inventory, I explored the concept of what assets should an organization actively manage and track. The following graphic was introduced as part of a larger concept known as the IM/IT Lifecycle.

IM/IT Inventory-Model with sample mappings

To Include or Not to Include – that is the Catalog?

The purpose of the blog series was to try to answer the question, which bit of technology should be included, or not, in things like an inventory of applications. The conclusion was pretty much, if it has value – include it – and if it will take a material amount of effort to recreate it, definitely include it.

Alas there is a definitional challenge when it comes to building application catalogs, namely WHAT IS an application? Some definitions available include:

ITIL – Application: Software that provides functions which are required by an IT service. Each application may be part of more than one IT service. An application runs on one or more servers or clients. See also application management; application portfolio. (Axelos.com; glossary, accessed 2018-01-27).
COBIT – Application: A computer program or set of programs that performs the processing of records for a specific function. Scope Notes: Contrasts with systems programs, such as an operating system or network control program, and with utility programs, such as copy or sort. (www.isaca.org; glossary, accessed 2018-01-27).
Techopedia – Application software is a program or group of programs designed for end users. These programs are divided into two classes: system software and application software. While system software consists of low-level programs that interact with computers at a basic level, application software resides above system software and includes applications such as database programs, word processors and spreadsheets. Application software may be grouped along with system software or published alone. Application software may simply be referred to as an application. (www.techopedia.org, accessed 2018-01-27).

Why Ownership Matters

All 3 definitions try to get their arms around the question, how long is a piece of string. Unfortunately the string is only going to get longer as applications pop up on smart phones, are meshed with AI or are used by an organization but inhabit the cloud. Nevertheless, the definition is important because no matter where/how/who etc. the application is run – an organization must still keep internal accountability for its creation, maintenance, usage, information management and ultimate disposal.

Accountability is important because if service is increasingly delivered by technical means (including robots, AI, cloud and the Borg) then human accountability for its proper functioning and adherence to business objectives becomes more, not less, important.

Another important reason to define an application is to provide ownership both technical and business. This concept will become both more difficult and more important as applications become completely embedded in business processes and wink in/out of existence because of an accelerated development time frame.

But is ‘IT’ Spoken For?

One of the challenges of trying to assign ownership is that busy business users don’t want to be bothered with having to own technical resources such as a flux capacitor or an anti-matter chamber (these exist, right?). They want to focus on their widget production system without being bothered with tech-esse. However, all the technical bits need to be ‘owned’ by someone for no other reason than to ask: ‘can we turn it off‘? To assist with this, I am proposing a 3 tier ownership structure.

Level/Description	Typical Owner	Examples
1. Strategic. Technology in this group is often at the system level meaning that it is composed of 2 or more applications. A strategic system is often long-lived and may directly or indirectly support multiple areas of the organization and product lines.	The most senior person in an organization that relies on the technology for their immediate accountability. Resist the urge to give everything to the President/CEO – this is the day-to-day senior owner, e.g. the VP of Operations. The owner may sometimes be known as the information controller. I like this as it focuses on the value of a system (information) rather than the means of a system (technical).	ERP system including manufacturing, inventory, sales, etc. Production or product support system
2. Tactical Application. A bit of software that may support one or more business/technical needs. Each tactical application has a single or a few outputs it produces. It may exist on its own and/or it may be part of a larger system.	Because most entries in an organization’s application catalog fall into this category, it is not surprising that most owners are middle level managers. The biggest challenge in this category is what is in or out. See the above blog for some thoughts on this.	Speciality reporting tools for finance/ marketing. Stand alone database to track a single business function.
3. System/Operations. A bit of software that the techies are primarily aware of… until it does not work of course. This includes ITIL system programs but may include utilities that business users rely on to operate a tactical application.	Although these applications support a business user, their owners are the technical folks. In this way, the technical areas provide a service to the business/ tactical applications.	Print utility, payment control system integrated with a bank, network or firewall software.

Like most things in life there are definite grey areas between the above 3. This is where professional judgement comes to assign a bit of code to the right category and therefore to the correct accountable person. In doing the assignment, I would suggest that an organization use the following rubric in assigning ownership.

Start High – Work Low: there is an inclination to make all technical things belong to the techies. Therefore, all systems start with being owned by the highest possible level until they are pushed down based on the following guidelines.
Who Gets to Change or Turn IT Off: this guideline is the contrary to the above, who gets to make changes to the bit of software. Ideally this should be pushed down as low as possible. When in doubt, who is responsible to to turn the dang thing off when the application has outlived its usefulness.
The User/Customer, Disenfranchised and the Veto: Because the first two purposely try to move ownership either up or down an organization, the last consideration is consider the outcome.
1. Who is nearest to the user/customer of the bit of software and therefore can make the best determination whether or not cinnamon red on a burnt orange background is a good colour scheme for web page. Move ownership down when this factor is important.
2. Who are the internals and externals who are affected but are disconnected from the decision-making choice; these may be users or a few degrees separated from the user. Move ownership up when this factor is important.
3. Who has a veto either explicitly or implicitly? What are the internal and external politics of the bit of software? If there are few such considerations, move ownership down; if there are many such considerations, move the software up.
The Times are a Changin’: Use professional judgement to make a determination and then plan to periodically or ad hoc return to the decision. Hopefully ownership generally moves down as a system matures and becomes stable – a change in the environment may require it to go up for a bit..

Conclusion and Other Ownership Constructs

The above takes a bit of a traditional view of ownership and purposely avoids such knotty issues as open source software or software as a service. My expectations is that an organization with lots of applications to document (in particular governments) should spend time on these assets and then turn their attention to the more esoteric. If an organization really does not own any applications then this discussion is a bit mute and academic anyway.

Let me know if the above model is useful and how you would improve it!

Against the Gods

Posted on January 14, 2018 by Frank SAPAA

Peter L. Bernstein wrote “Against the Gods: The Remarkable Story of Risk” in the late 1990s, well before the financial meltdown of 2008 or the dot come bubble burst a few years later. The book itself is a good refresher of the history of mathematics and provides a reasonably entertaining and well written history of risk. Before getting to the book though, a quick detour about Bernstein himself.

A Life Well Lived

Bernstein died in 2009 at the age of 90. Over those nine decades he was born into relative wealth, served as an officer in World War II, worked for the US federal government, taught university, took over his father’s investment business, sold the business for a tidy sum, wrote ten books – 3 in his late 80’s and became a respected academic. WHEW

For anyone of us, a few of the above accomplishments in our lifetime would be gratifying (including making it to 90) let alone the number he accomplished. In other words, Bernstein can be said to have had a life well lived.

The Good News from the Gods

Some of the reviews on http://www.goodreads.com have critiqued Bernstein’s writing style. It is not the most elegant I have ever read but it was reasonably engaging and not too technical. He takes a chronological approach to risk but this is really on the mathematics of risk.

He notes the restrictions early western mathematicians had including the Roman numeric system, the enlightenment and renaissance (to get beyond the notion that all things are pre-ordained by God), bookkeeping, forecasting, algebra and an unfinished game of chance.

To this last point, the question was how best to divide up the winnings of a game with a fixed number of iterations of the game that was partially played. This question spurred the mathematics to ask the question about probabilities and the future. Risk management was born.

From the renaissance, Bernstein takes us through the development of more advanced mathematics, game theory and then finally the rise of the Quants in computerized trading.

In other words, the book is a good and reasonably accessible refresher on the history of mathematics and specifically the development of statistics and financial mathematics. Bernstein does explore some of the human side of risk. For example he discusses those old favorites of behavioral economics: loss aversion, regression to the mean / Prospect Theory, ambiguity aversion, etc. In other words, a good historical romp that ties in some familiar and some unfamiliar details into a reasonably good overview of the mathematics of risk…

The Bad News about the Gods

… and therein lies the biggest problem with the book, big on math short on the story of risk. There is so much more that Bernstein could have incorporated into the book. For example

How is risk perceived and managed in different cultures.
How have the Christian and Muslim beliefs about risk and interest rates changed their respective trajectories.
What has been the impact over the past 50 years on risk management given that risk has now being overtly managed.
How have institutions such as the military, healthcare or pharmaceuticals changed in how they managed risks.
What was the impact of large-scale events on the acceptance and management of risk, for example did the Black Death make people more or less risk averse and how did this affect risk management.

In a way it is too bad that Bernstein wrote the book when he did or that he did not write it say 10-12 years later. I would have been interested in his views on the 2008 financial crisis and the work of Nicholas Taleb, etc. who also discussed risk, statistics and randomness.

In the End

So, a good read if you enjoy history, mathematics and what a fuller understanding of the concepts of risks. A revised edition would be great, or even better, a second volume with more depth and breadth. Never the less a read that rounds out anyone interested in Risk Management.

A few Quotes and Thoughts

Publisher’s Description: With the stock market breaking records almost daily, leaving longtime market analysts shaking their heads and revising their forecasts, a study of the concept of risk seems quite timely. Peter Bernstein has written a comprehensive history of man’s efforts to understand risk and probability, beginning with early gamblers in ancient Greece, continuing through the 17th-century French mathematicians Pascal and Fermat and up to modern chaos theory. Along the way he demonstrates that understanding risk underlies everything from game theory to bridge-building to winemaking.

p. 15: Time is the dominant factor in gambling. Risk and time are opposite sides of the same coin, for if there were no tomorrow there would be no risk. Time transforms risk, and the nature of risk is shaped by the time horizon: the future is the playing field. Time matters most when the decisions are irreversible.

p. 197: The essence of risk management lies in maximizing the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and the linkage between effect and cause is hidden from us.

p. 228: Keynes argued that interest is a reward for parting with liquidity, not for refraining from consumption.

p. 232: Game theory says that the true source of uncertainty is in the intentions of others.

PRMM – How is That Planning Thing Working Out for You?

Posted on January 9, 2018 by Frank SAPAA

This is the second in a series of blogs on a Practical Risk Management Method or PRMM. At the bottom of this blog is a refresher of the other steps. This step’s premise is don’t separate your planning activities from your risk management activities. In other words:

Planning = Risk Management. Planning is ultimately about managing uncertainty which is a fancy name for Risk. At this point you may be saying:

Of Course: we already do this. Good on you, see you at the next blog!
Great Idea: this may be incrementally more work during the planning process but ultimately over all less effort for the organization.
What is This Planning Thing you Speak Of: hmmm, we may have identified your top risk.

I am afraid I can’t help you if you fall into the last category but hopefully these blogs can help you if you with the first two.

Continue reading →

Practical Risk Management Model

Posted on January 7, 2018 by Frank SAPAA

Is traditional risk management practical? If so, why do so many organizations struggle to do it well? As a quick refresher here are the three steps of virtually all risk management methods:

Establish business objectives.
Identify and quantify some or all of the risks that may prevent the organization from achieving these objectives.
Figure out what you are going to do with the resulting risks (e.g. ignore, manage, transfer, assign owners, etc.).

An Practical Risk Management Method (PRMM)

What makes risk management impractical is that it is often a bolt on and/or a parallel activity. In addition, risk management often gets bogged down in too many risks and not enough value add (see my blog “Guns, Telephone Books and Risk?” for more on this). PRMM recommends the following steps:

Planning = Risk Management. Incorporate risk management into existing operational, tactical and strategic planning; don’t separate the two. Why? Because planning is how organizations manage uncertainty which is a fancy name for Risk.
Are You Any Good at Change? Evaluate how well your organization responds to change (e.g. when uncertainty becomes certain). When the unexpected happens, was your response chaotic and uncoordinated or did it go more or less to plan?
How Strong is your ARM? ARM or Antifragile Risk Management is a system that focuses on building robust and resilient organizations. While step 2 above measures the organization in action, this step anticipates your organization’s uncertainty resiliency.
A Certain Test of Uncertainty. The organization’s risk/opportunity log is used to stress test the work done above. Testing measures the robustness of the organization and the scope and reasonableness of the collected risks. This is the traditional risk management step in PRMM.
Don’t Stop. Modify/improve your plans and keep going. All of the above activities are meant to be both periodic (e.g. the annual planning process) or continuous.

My next blog are some thoughts on step 1 above, integrating risk management into the planning processes of the organization.

Organizational Biology

How organizations really work

Monthly Archives: January 2018