All Posts by Bob Lewis

|In: App Dev Methodologies|Last Updated:

I don’t get it.

I just read Lucas Carlson’s excellent overview of microservices architecture in InfoWorld. If you want an introduction to the subject you could do far worse, although I confess, it appears microservices architecture violates what I consider to be one of the fundamentals of good architecture. (It’s contest time: The first winning guess, defined as the one I agree with the most, will receive a hearty public virtual handshake from yours truly.)

My concern isn’t about the architectural value of microservices vs its predecessors. It’s that by focusing so much attention on it, IT ignores what it spends most of its time and effort doing.

Microservices, and DevOps, to which it’s tied at the hip, and almost all variants of Agile, to which DevOps is tied at the ankle, and Waterfall, whose deficiencies are what have led to Agile’s popularity, all focus on application development.

WAKE UP!!!!! IT only develops applications when it has no choice. Internal IT mostly buys when it can and only builds when it has to. Knowing how to design, engineer and build microservices won’t help you implement SAP, Salesforce, or Workday, to pick three examples out of a hat. Kanban and Scrum might be a bit more helpful, but not all that much. The reasons range from obvious to abstruse.

On the obvious end of the equation, when you build your own solutions you have complete control of the application and information architecture. When you buy solutions you have no control over either.

Sure, you can require a microservices foundation in your RFPs. Good luck with that: The best you can successfully insist on is full access to functionality via a RESTful (or SOAPy, or JSON-and-the-Argonauths) API.

Halfway between obvious and abstruse lies the difference in cadence between programming and configuration, and its practical consequences.

Peel away a few layers of any Agile onion and you’ll find a hidden assumption about the ratio of time and effort needed to specify functionality … to write an average-complexity user story … and the time needed to program and test it. The hidden assumption is that programming takes a lot longer than specification. It’s a valid assumption when you’re writing Angular, or PHP, or Python, or C# code.

It’s less valid when you’re using a COTS package’s built-in configuration tools, which are designed to let you tweak what the package does with maximum efficiency and minimum risk that the tweak will blow up production. The specify-to-build ratio is much closer to 1 than when a team is developing software from scratch, which means Scrum, with its user-story writing and splitting, backlog management, and sprint planning, imposes more overhead that needed.

And that ignores the question of whether each affected business area would find itself more effective by adopting the process that’s built into the COTS package instead of spending any time and effort adapting the COTS package to the processes they use at the moment.

At the full-abstruse end of the continuum lies the challenge of systems integration that’s lying in the weeds there, waiting to nail your unwary implementation teams.

To understand the problem, go back to Edgar Codd and his “twelve” laws of relational data normalization (there are thirteen of them; his numbering starts at zero). Codd’s framework for data normalization is still the touchstone for IT frameworks and methodologies of all kinds, and just about all of them come up short in comparison.

Compare the process we go through to design a relational database with the process we go through to integrate and synchronize the data fields that overlap among the multiple COTS and SaaS packages your average enterprise needs to get everything done that needs to get done.

As a veteran of the software wars explained to me a long time ago, software is just an opinion. Which means that if you have three different packages that manage employee data, you bought three conflicting opinions of what’s important to know about employees and how to represent it.

Which in turn means synchronizing employee data among these packages isn’t as simple as “create a metadata map” sounds when you write the phrase on a PowerPoint slide.

To the best of my knowledge, nobody has yet created an integration architecture design methodology.

Which shouldn’t be all that surprising: Creating one would mean creating a way to reconcile differing opinions.

And that’s a shame, because a methodology for resolving disagreements would have a lot more uses than just systems integration.

Comments

|In: Leadership|Last Updated:

Let’s see if we can pull this all together.

In recent weeks we’ve talked about teams and team dynamics. We’ve talked about the too-often perverse relationship between knowledge and certainty. We’ve talked about culture and how its self-reinforcing nature can result in appalling behavior just as it can help bring out the best in people.

Teams, as described here from time to time, are groups of people who trust each other, and are aligned to a common purpose.

Toss in some additional reflection and discussions with various correspondents over the past few weeks and it’s clear that while trust and alignment are important team-ness ingredients, they aren’t the whole recipe.

Another is interdependence. In the world of sports, members of baseball, football, and basketball teams depend on each other move-by-move to get the job done. Golfers competing in the Ryder Cup, in contrast, do root for each other, but don’t nudge the ball when nobody’s looking. Likewise tennis players in the Davis Cup who presumably don’t use mirrors to try to blind members of opposing teams from the stands.

The world of business can be even more extreme: Many companies pit members of the so-called “sales team” against each other in the quest to receive the sales incentives that only go to the top 10% of producers.

And some business leaders still buy into the old MBO (management by objectives) method of setting management goals, assuring that each manager will do whatever it takes to achieve his or her objectives whether or not it’s at the expense of other members of the “management team” trying to achieve their goals.

Does this mean the “sales team” and “management team” are only teams in scare quotes?

Not entirely, because of another ingredient of team-ness. That’s affinity – a shared sense of identity that’s independent of both trust and purpose. Independent, that is, except for a desire to beat other, competing groups.

Which gets us to culture. Shared identity can be and often is independent of trust and purpose. It’s never independent of culture.

Here in KJR-land our working definition of culture is how we do things around here. It’s the informal, unwritten rules the affinity group … the tribe … enforces far more strictly and ruthlessly than HR enforces any of what’s spelled out in the company’s policies and procedures.

Identity politics … tribalism, that is … isn’t limited to politics.

Because if it were, how would you explain soccer riots?

It’s time to connect all this theory to your work-a-day responsibilities as an IT manager.

As the golden rule of engineering is form follows function, start with what you want. I imagine that in most situations, most of the time, you want the men and women who work in your organization to accomplish important results.

Most of the time, they’ll accomplish important results more effectively as a result of teamwork than of working in isolation. So you need to encourage team-building in the trust-and-alignment sense.

But like it or not, achieving trust and alignment is hard work that requires constant, steady leadership. That’s in contrast to achieving an us vs them tribal sense of identity, complete with unwritten rules governing how we do things around here. You’ll get that in spite of your best efforts to prevent it.

What you can do, sometimes, if you’re lucky and the wind is blowing in the right direction, is to channel your employees’ natural tendency to form up into rival tribes, so tribal and team identities coincide, or at least overlap heavily.

It isn’t a perfect solution by any means. Yes, project teams that have a strong sense of tribal identity will work harder and collaborate better internally than employees assigned to a project whose sense of team identity is limited to trust and alignment to a common purpose.

But that same sense of tribal identity will make the team less likely to collaborate with other teams they think of as the them to their own us.

Is there anything you can do to limit the extent to which the tribes take over?

There is. You can keep projects short, so project-based tribes disband before their tribalism starts to dominate the cultural landscape. And, you can populate new project teams cross-functionally, redefining us and them frequently enough to break down tribal animosities faster than new ones can form.

Or, you can do what most managers seem to do: Hope for the best, complementing hope with an occasional lecture about how we’re all on the same team.

That’ll work well.

Comments