Pride, Prejudice, and Professionalism in the Business of IT

interior of a 1958 Plymouth Savoy

Twenty-plus years in IT have led me to believe that there are very few absolutes when it comes to software systems. Two that do seem to hold true are these:

  1. Creating systems is esteemed far more highly than maintaining systems.
  2. Systems that are not maintained, will decay.

There are a variety of reasons for this situation, many of which are baked into the architecture of the enterprise. Regardless of the why, however, the two facts remain. Without a response to those issues, entropy is inevitable.

Over the past few days, I’ve seen several blog posts by two different authors dealing with this situation in two different ways:

Jason complains about the non-technical “leadership class” in his first post:

And hence we get someone making the big decisions about healthcare who knows nothing about medicine or about running hospitals or ambulance services. And we get someone in charge of all the schools who knows nothing about teaching or running a school. And we get someone in charge of a major software company whose last job was being in charge of a soft drinks company. And so on.

Again, this is fine, if they leave the technical decisions to the technical experts. And that’s where it all falls down, of course. They don’t.

The guy in charge of the NHS insists on telling doctors and nurses how they should do their jobs. The woman in charge of UK schools insists on overriding the expertise of teachers. The guy in charge of a major software company refuses to listen to the engineers about the need for automated testing. And so on.

This is the Dunning-Kruger effect writ large. CEOs and government ministers are brimming with the overconfidence of someone who doesn’t know that they don’t know.

In his second post he follows up with how to respond:

My pithy – but entirely serious – advice in that situation is Do It AnywayTM.

There are, of course, obligations implied when we Do It AnywayTM. What we’re doing must be in the best interests of stakeholders. Do It AnywayTM is not a Get Out Jail Free card for any decision you might want to justify. We are making informed decisions on their behalf. And then doing what needs to be done. Y’know. Like professionals.

I disagree. Strenuously.

If you go to the doctor and they tells you that you will need surgery at some point for some condition, would you expect to be forcibly admitted and operated on immediately?

If you were charged with a crime, would you expect your attorney to accept a plea bargain on your behalf without consultation or prior permission?

If neither of those professionals would usurp the right of their client/patient to make their own informed decision, why should we? Both of those examples would be considered malpractice and the first would be criminal assault in addition. Therefore, I disagree that acting on someone’s behalf without their knowledge or consent is a viable option.

John’s approach, rejecting helplessness and confronting the issues by communicating the costs (with justifications/evidence) is, in my opinion, the truly professional approach. We have a responsibility to make the problem visible and continue making it visible. We also have a responsibility to operate within the limits we’re given. We know far more about our area than someone higher up the management chain, but, that does not equate to knowing more in general than those higher up the management chain. Ignorance is relative. Micro-managing, getting deeper in the weeds than you need to is ineffective. If, however, you’re in the weeds, do you have the information necessary to say that the issue being “interfered with” is one without higher-level consequences? Dunning-Kruger can cut a wide swathe. Trust needs to cut both ways.

Imagine riding as a passenger in a car. You see the car drifting closer and closer to the shoulder. Do you point it out to the driver or do you just grab the wheel? You might prevent an accident or you just might cause one by steering into a vehicle coming up from behind that you didn’t see from your vantage point.

[Plymouth Savoy photo by Christopher Ziemnowicz via Wikimedia Commons]

Building a Legacy

Greek Trireme image from Deutsches Museum, Munich, Germany

 

Over the last few weeks, I’ve run across a flurry of articles dealing with the issue of legacy systems used by the U.S. government.

An Associated Press story on the findings from the Government Accountability Office (GAO) issued in May reported that roughly three-fourths of the $80 billion IT budget was used to maintain legacy systems, some more than fifty years old and without an end of life date in sight. An article on CIO.com about the same GAO report detailed seven of the oldest systems. Two were over 56 years old, two 53, one 51, one 35, and one 31. Four of the seven have plans to be replaced, but the two oldest have no replacement yet planned.

Cost was not the only issue, reliability is a problem as well. An article on Timeline.com noted:

Then there’s the fact that, up until 2010, the Secret Service’s computer systems were only operational about 60% of the time, thanks to a highly outdated 1980s mainframe. When Senator Joe Lieberman spoke out on the issue back in 2010, he claimed that, in comparison, “industry and government standards are around 98 percent generally.” It’s alright though, protecting the president and vice president is a job that’s really only important about 60 percent of the time, right?

It would be easy to write this off as just another example of public-sector inefficiency, but you can find these same issues in the private sector as well. Inertia can, and does, affect systems belonging to government agencies and business alike. Even a perfectly designed implemented system (we’ve all got those, right?) is subject to platform rot if ignored. Ironically, our organizations seem designed to do just that by being project-centric.

In philosophy, there’s a paradox called the Ship of Theseus, that explores the question of identity. The question arises, if we maintain something by replacing its constituent parts, does it remain the same thing? While many hours could be spent debating this, to those whose opinion should matter most, those who use the system, the answer is yes. To them, the identity of the system is bound up in what they do with it, such that it ceases to be the same thing, not when we maintain it but when its function is degraded through neglect.

Common practice, however, separates ownership and interest. Those with the greatest interest in the system typically will not own the budget for work on it. Those owning the budget, will typically be biased towards projects which add value, not maintenance work that represents cost.

Speaking of cost, is 75% of the budget an unreasonable amount for maintenance? How well are the systems meeting the needs of their users? Is quality increasing, decreasing, or holding steady? Was more money spent because of deferred maintenance than would have been spent with earlier intervention? How much business risk is involved? Without this context, it’s extremely difficult to say. It’s understandable that someone outside an organization might lack this information, but even within it, would a centralized IT group have access to it all? Is the context as meaningful at a higher, central level as it is “at the pointy end of the spear”?

Maintaining systems bit by bit, replacing them gradually over time, is likely to be more successful and less expensive, than letting them rot and then having a big-bang re-write. In my opinion, having an effective architecture for the enterprise’s IT systems is dependent on having an effective architecture for the enterprise itself. If the various systems (social and software) are not operating in conjunction, drift and inertia will take care of building your legacy (system).

[Greek Trireme image from Deutsches Museum, Munich, Germany via Wikimedia Commons]

Form Follows Function on SPaMCast 399

SPaMCAST logo

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 399, features Tom’s essay “Storytelling: Developing The Big Picture for Agile Efforts”, Kim Pries on deliberate practice, and a Form Follows Function installment on customer-centricity for IT.

Tom and I discuss my post “A Meaningful Manifesto for IT”. It seems obvious that the business of IT is meeting needs, but how many organizations are really happy with what they’re getting? The prevalence of “shadow IT” would seem to indicate that there’s some real discontent.

You can find all my SPaMCast episodes using under the SPAMCast Appearances category on this blog. Enjoy!

The Hidden Cost of Cheap – UX and Internal Applications

Sisyphus by Titian

Why would anyone worry about user experience for anything that’s not customer-facing?

This question was the premise of Maurice Roach’s post in the Zühlke blog, “Empathise with your users or you won’t solve their problems”:

Bring up the subject of user empathy with some engineers or product owners and you’ll probably hear comments that fall into one of the following categories:

  • Why do we need to empathise when the requirements tell us all we need to know about the problem at hand?
  • Is this really going to improve anything?
  • Sounds like an expensive waste of time
  • They’ll have to use whatever they’re given

These aren’t unexpected responses, it’s easy to put empathy into the “touchy feely”, “let’s all hug and get along” box of product management.

Roach’s answers:

Empathy does a number of things, but mainly it increases the likelihood that the delivery team will think of a user and their pain points when delivering a feature.

If an engineer, UX designer or product owner will has sat with a user, watched them interact with their current software or device they will have an understanding of their frustrations, concerns and impediments to success. The team will be focused on creating features with the things they have witnessed in mind, they’re thinking about how their software will affect a human being and no amount of requirement documentation will give them that emotional connection.

Empathy can also help to develop a shared trust in the application development process. The users see that the delivery team are interested in helping to solve their problems and the product delivery team see the real users behind the application.

All of these are valid reasons, but the list is incomplete. All of these answer the question from a software development point of view. To his credit, Roach pushes past the purely technical aspects into the world of the user. This expanded exploration of the context is, in my opinion, absolutely essential. What’s presented above is an IT-centric viewpoint that needed to be married with a business-centric viewpoint in order to get a fuller picture.

Nick Shackleton-Jones, in his post “The Future Is… Organisational Usability!”, outlined on the problem:

Here’s how your organisation works: you hire people who are increasingly used to a world where they can do pretty much anything via an app on their iPhone, and you subject them to a blizzard of process, policy, antiquated systems and outdated ways of working which pretty much stop them in their tracks, leaving them unproductive and demoralised. Frankly, it’s a miracle they manage to accomplish anything at all.

As he notes, enterprises are putting a lot of effort into digital initiatives aimed at making it easier for customers to engage with them. However:

…if we are going to be successful in future we need to make it much easier for our people to do their jobs: because they are going to be spending less time with us, and because we want engagement and retention, and because if we require high levels of capability (to work our complex systems) then our resourcing costs will go through the roof. We have to simplify ‘getting stuff done’. To put it another way: in an ideal world, any job in your organisation should be do-able by a 12-yr old.

While I disagree that “any job in your organisation should be do-able by a 12-yr old”, Shackleton-Jones point is well-taken that it is in the interests of the business to make it easier for people to do their jobs. All aspects of the system, whether organizational, procedural or technological, should be facilitating, not hindering, the mission. Self-inflicted, unnecessary impediments are morale-killers and degrade both effectiveness and efficiency. All three of these directly impact customer-experience.

While this linkage between employee user experience and customer experience makes usability important for line of business systems (both technological and social), it has value for peripheral systems as well. Time people spend on ancillary tasks (filling out time sheets, requesting supplies, etc.) is time not spent on their primary duties. You may not be able to eliminate those tasks, but you can minimize their expense by making them quick and easy to complete. The further someone’s knowledge/skill/experience level gets from “do-able by a 12-yr old”, the bigger the savings by paying attention to this.

Rather than asking if you can afford to pay attention to user experience, you might want to ask whether you can afford not to.

Enterprise Architecture and the Business of IT

Turning Gears Animation

I’ve been following Tom Graves and his Tetradian blog for quite a while. His view of Enterprise Architecture (EA), namely that it is about the architecture of the enterprise and not just the enterprise’s IT systems, is one I find compelling. With some encouragement on Tom’s part, I’ve begun touching on the topic of EA, although in a limited manner. When it comes to enterprise architecture, particularly according to Tom’s definition, I consider myself more of a student than anything else. I design software systems and systems of systems, not the enterprises that make use of them.

However…

I’m finding myself drawn to the topic more and more these days. I’m finding it more and more relevant to my work. The fractal nature of social systems using software systems is a major theme of the category “Organizations as Systems” on this site. If the parts fit poorly, then the operation of the system they comprise will be impeded. A good way to ensure the parts fit poorly is to fail to understand the context in which they will inhabit. So while I may not be designing the social system which my systems fit into, an understanding of how that system functions is invaluable, as is an understanding of how my social system (IT) interacts with my client’s social system (the rest of the business) to further the aims of the enterprise.

Tom’s latest post, “Engaging stakeholders in health-care IT”, is an excellent example of how not to do things. In the post, Tom discuss attending a conference on IT in healthcare where the players had no real knowledge about healthcare. They couldn’t even identify the British Medical Journal or the Journal of the American Medical Association, much less have an idea about what issues might be found in the pages of those publications. They didn’t feel that was a problem:

Well, they didn’t quite laugh at me to my face about that, but in effect it was pretty close – a scornful dismissal, at best. In other words, about the literally life-and-death field for which they’d now proclaimed themselves to be the new standard-bearers, they were not only clueless, but consciously clueless, even intentionally clueless – and seemingly proud of it, as well. Ouch… At that point the Tarot character of ‘The Fool’ kinda came to mind – too self-absorbed to notice that he’s walking straight over a cliff

While I recently advocated embracing ignorance, it was in the context of avoiding assumption. The architect will know less about the business than a subject matter expert who will most likely know less than the end user on the pointy end of the spear. The idea is not to remain ignorant of the domain, but to avoid relying on our own understanding and seek better sources of information. It’s unreasonable to think we can design a solution that’s fit for purpose without an understanding of the architecture of the problem, and make no mistake, providing solutions that are fit for purpose is the business of IT.

A Meaningful Manifesto for IT

“Customer-centricity” is one of the biggest tags in the tag cloud to the right. My first post this year was “Is 2016 the Year for Customer-Focused IT?”. It’s a concept that I find vitally important to IT for the simple reason that to the extent that IT is not fit for purpose, it’s a waste of money. How well (or not) we’re meeting the needs of our clients determines that level of fitness.

Seth Godin’s recent post, “A manifesto for small teams doing important work”, contains a great deal of wisdom for IT, primarily because it starts with a customer-centric approach:

If you make a promise, set a date. No date, no promise.

If you set a date, meet it.

If you can’t make a date, tell us early and often. Plan B well prepared is a better strategy than hope.

Talk to everyone as if they were your boss, your customer, the founder, your employee. It’s all the same.

It works because it’s personal.

Trust is a crucial basis for a relationship, and IT is in the relationship business, or it’s operating at a disadvantage. IT is pricey, so without the value provided by a good relationship, there is a tremendous incentive to shop based on price. If corporations had been better at managing outsourced software development, insourcing might not be the current trend. The current issue of “shadow IT” certainly belies the notion that companies are happy with the service they’re getting.

IT doesn’t exist in a vacuum. IT systems, the social system(s) by which they’re provisioned, and the social systems which make use of them must all work together in reasonable harmony or risk dysfunction. I’m of the opinion that embedded IT (whether literal or figurative) would be useful in bridging the gap. Humility and responsibility would go a long way toward helping. Likewise, tailoring solutions to problems would help better than chasing fads is a good strategy. Meeting needs will get a better reception than attempts to control, particularly when we attempt to control what we don’t own. At the very least, we need to learn to communicate.

Those are principles I can get behind.

The Business of IT – Customers, Clients, and Fit for Purpose

Nesting Doll

Over the past few months, I have touched on a variety of what might seem to be disparate topics: the need for architects (or at least architectural design), estimates, organizations as systems/enterprise architecture, customer-centricity, and IT management and governance. I suspect the trend will continue for a while, so it’s time for a post to explicitly tie things together.

The concept of “organizations as systems” is the cornerstone. Software systems do not exist in isolation, but within a fractal set of contexts, each of which are systems themselves. These systems serve as the ecosystem for those they contain and will ultimately end in one or more social systems. Understanding the ecosystem is critical to ensuring that its component systems are fit for purpose, otherwise we risk trying to introduce fish into a desert.

The social system context is, in my opinion, key. Information technology delivery can take place in a wide variety of ways, but a useful high-level differentiation is that between delivery of an off-the-shelf product versus delivery of a service. Is the customer a client?

These two sentences, left alone, could be a source of confusion. Precision isn’t one of the English language’s strong points. Not all products are off-the-shelf, sometimes the service we deliver is the creation of a bespoke product (ultimately, the end user is concerned with the product that they will use, not the project by which we created it). Likewise, in my opinion, clients are customers, just not all customers are clients. In my career, I’ve exclusively dealt with client customers, so I tend to use the two terms interchangeably. That becomes a problem when we have a client that isn’t being treated like a client. Seth Godin’s recent post explained the difference nicely:

The customer buys (or doesn’t buy) what you make.

The client asks you to make something.

The customer has the power to choose, but the client has the power to define, insist and spec.

There is a large number of potential customers, and you make for them before you know precisely who they are.

There are just a relative handful of clients, though, and your work happens after you find them.

If a customer doesn’t like what’s on offer, she can come back tomorrow. If the client doesn’t like what you deliver, she might leave forever.

When a vendor fails to treat its customers as clients, they risk losing the client. When an in-house IT organization treats fails to treat its captive customers as clients, the result is “Shadow IT”. When that result is complained about, it betrays a shocking lack of awareness on the part of the complainer.

A client will have a hierarchy of concerns in relation to IT. The client’s main interest is the job that they’re doing (or will be doing) with a product. Their concern with the product will be shaped by that, as will their concern with the process by which the product is delivered. We shouldn’t be surprised when things that don’t promote the client’s welfare (or, at least, aren’t presented in that manner) are met with a lack of interest. We definitely shouldn’t be surprised when things that are seen as a net negative to the customer are met with hostility. Understanding and respecting the client’s point of view is required to avoid damaging our credibility and relationship with them.

Meeting the needs of my clients is my objection to #NoEstimates. Clients may have questions that require estimates to answer. In “Estimates – Uses, Abuses, and that Credibility Thing Again”, I listed several that were taken from a post by a prominent #NoEstimates advocate. In my opinion, those questions become my concern by virtue of being my client’s concern. Suggesting, as that advocate does, that they need different questions, is not serving their needs.

Just as the infrastructure environment can influence design decisions, so can the social environment. While it is certainly possible to deliver IT in an environment where the clients’ needs are largely ignored, doing so is detrimental to the clients, to the providers, and to the organization(s) to which they belong. We wouldn’t try to force a square peg in a round hole and we shouldn’t try to force ill-fitting solutions on those who depend on our work. Products generally work best when they’re designed to be used in the way they’re used. The same holds true for services.

[Recursive Matrena 01 image by Vahram_Mekhitarian via Wikimedia Commons]

Updated 4/8/2016 to fix a broken link.