All Posts by Bob Lewis

|In: Process Management and Improvement|Last Updated:

“Who are you going to believe?” Groucho Marx famously asked, “Me or your own eyes?”

The Groucho Question came to mind as I read an intriguing, if conspiracy-oriented opinion piece by James Schmitz Jr., a senior economist at the Federal Reserve Bank of Minneapolis. Schmitz’s contention is that home-building is trapped in 19th century technologies and methods that have prevented productivity increases in that sector for a matter of decades. (“Homebuilding must modernize,” StarTribune, 5/2/2021).

His solution: “Rather than manufacturing homes in factories, they are constructed outside, with a centuries-old technology sometimes called the “stick-built” method.”

He’s the “Me” part of the Groucho-ism. As one who consults on and writes about matters of organizational effectiveness, I found his contention appealing.

As the owners of a downtown condominium who, by HOA mandate had been required to have our balcony door replaced … twice; the first replacement having been problematic … my wife and I recently had the opportunity to see Schmitz’s theory applied in actual reality (and isn’t it strange to live in an era where I have to specify which reality I’m writing about).

We were Groucho’s “… or your own eyes,” as we watched two clearly expert individuals remove the offending door panels and replace them with (presumably) more serviceable ones. To get the job done they had to deal with perhaps six situations that required significant expertise and ingenuity.

It occurred to me that while the door panels had been manufactured in a factory – they were the result of a well-defined process – their installation was clearly and unavoidably a practice.

Why this matters to you: Here in KJR reality we’ve frequently discussed the difference between processes and practices; processes being how work gets done in factories, with their repeatable, predictable steps; practices being how work gets done in hospitals and law offices, where no two cases are ever exactly alike and work must be adapted to each specific situation.

We consultants frequently advise clients to turn case-by-case kinds of work into metaphorical factories so they can perfect their techniques and get results that are more repeatable and predictable. I’ve been guilty of this myself, although I hope with enough qualifiers that I haven’t overpromised the ease and simplicity of the result.

The differences between process and practice aren’t “mere” semantics, not that there’s anything truly mere about semantics in the first place. It’s also fair to say that to the extent it’s possible to redefine how work gets done so it’s less of a craft or practice and more of a manufacturing-like process, defect rates and incremental costs will, in most cases, decrease.

It’s just easier said than done. To turn any craft or process into a factory-like process, a key aspect of the transformation is to view each step in the work as responsible for reducing the variability or, looking through the other end of the telescope, increasing the predictability of what those responsible for the next step in the work will face.

If you’re building a house that means getting started by (based on my extraordinarily limited understanding of the trade) clearing and grading the lot, laying the foundation, and fixing variations in ground compressibility to avoid surprises when pouring the slab and laying cinder block.

When building an application it means (among other things) clearly defining the architecture and coding standards, writing consistent user stories, and determining interdependencies to avoid surprises when, depending on the application architecture, coding each module, service, microservice, or what-have you.

Bob’s last word: When we envision a factory we envision a conveyor belt that carries identical items to each step in the work.

When we envision most of what IT does for a living … or when we envision building a house … we don’t envision anything remotely like that.

Bob’s sales pitch: Looking for help improving the practice of improving business practices and processes? Here’s where to contact me so we can start a conversation.

Comments

|In: Architecture|Last Updated:

Dr. Yeahbut says:

We’ve been talking about APR (application portfolio rationalization) for two weeks now, and we could easily keep on talking about it for months without ever getting to the finish line.

So this week I’ll try to clean up a few odds and ends that might either help you get started or else might help you finish, starting with the most important:

Don’t undertake an APR project at all. Instead, set up an application portfolio management (APM) practice – a small group that manages the application disposition backlog, taking responsibility for (1) the guiding and governing principles of your technical architecture’s application layer; (2) the application layer’s ongoing holistic design and portfolio assessment; and (3) a mechanism through which all projects that make changes to the application layer do so in ways that improve it.

The APM practice could be a separate organization; it could be a new responsibility or focus of your enterprise architecture function; or it could be a re-launch of your architecture review board (ARB).

But be careful. The APM practice should provide leadership. Experience tells me that, as often as not, the APM practice does little more than add yet another flaming hoop teams have to jump through to get their work done – it becomes a bureaucratic barrier, not a facilitator.

Integrate integration. “Let’s talk about your application interfaces,” I asked a client application team. “Do you have the usual spiderweb to deal with?”

“Oh, no,” they told me. “We haven’t had a spiderweb in a long, long time. We call our interfaces ‘the hairball.’”

No matter how poor your application portfolio’s health, there’s high likelihood your integration is in even worse shape.

So before you start to rationalize your applications, set up a well-engineered integration framework. Every time you touch an application, make it an opportunity to clean up another corner of your interface spiderweb (or hairball).

What is an application, anyway? “Application” is a set with fuzzy boundaries and inclusion criteria. The confusion hits from several directions. The view from here: It’s an application if someone launches it to help them get work done. Some complicating factors and situations:

Some products are both platforms and applications. Take SharePoint. It is an application – you interact with it to get work done. But it’s also a platform you can use to build applications.

As you assess your application portfolio, include SharePoint-as-application. Also include applications built on the SharePoint platform. Don’t try to count the applications built on SharePoint as “SharePoint.” Each is a separate application.

Installed clients are … what, exactly? As more and more applications present their user interfaces through browsers this is less and less of an issue, but it hasn’t gone away entirely. If you have client/server-style applications that are still in production you’ll have to decide whether to include the client-side and server-side applications as a single entity or separately.

Either answer will work. Just be consistent about it.

Microservices are … what, exactly? Just my opinion: this is a rabbit hole you should step around carefully. Fall into it and you’ll never be seen again.

You’re better off dealing with microservices as platforms, not applications. This doesn’t make dealing with them easy. It makes them Someone Else’s Problem (or your problem but on different days of the week).

Keep track of your microservices the way you keep track of libraries. Applications rely on them, mucking them up can do a lot of damage, but they aren’t applications.

Avoid SPAs (single page architectures). I know it’s tempting. I’ve drawn these myself – diagrams that show all components of the application portfolio along with their affinities and interconnections, all in one place.

That is, SPAs usually turn into collections of dozens of boxes connected by multiple dozens of lines and arrows, all labeled in 6-point Arial type or smaller.

And all completely unverifiable.

Without exception, every architecture diagram should obey the rule of 7 plus-or-minus 2: It should include no more than between five and nine boxes; each box may be explored more deeply with a separate page that also contains between five and nine boxes.

Bob’s last word: Apply the rule of 7 plus-or-minus 2 to every kind of diagram, not just architecture diagrams – process flow “swim-lane” diagrams, for example. Human beings can make sense of seven connected boxes and be confident they’re right. We can’t make sense of seventy, even if our eyes are good enough to resolve their mousetype labels.

Bob’s sales pitch: CIO recently ran a piece by yours truly about the importance of a culture of honest inquiry for achieving your analytics goals. You’ll find it here, assuming you’re interested enough to click.

Comments