All Posts in App Dev Methodologies

|In: App Dev Methodologies|Last Updated:

Your resolutions for 2018:

Resolution #1: Send me ManagementSpeaks. Keeping an ear open for these is an excellent way to keep yourself grounded. Also, my supply is getting low.

Resolution #2: Send KJRs you like to your friends, family, colleagues, and especially people you don’t like and want to irritate. They’ll thank you. Except for the ones who won’t.

Resolution #3: Let me know how I’m doing … not only on the subjects I write about, but also on whether I’m writing about the right subjects.

Resolution #4: Give up on TOGAF.

This one might need a bit more explanation …

For those unlettered in the arcana of enterprise architecture, TOGAF stands for The Open Group Architecture Framework. According to the Open Group, TOGAF®, an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency.

Before diving into the important reasons to abandon TOGAF, a question: In what way is TOGAF proven? I Googled “TOGAF SUCCESS RATE” and came up dry. So far as I can tell neither the Open Group nor anyone else has even defined a TOGAF success metric, let alone tracked improvement against a baseline.

And a quibble: According to the above explanation, TOGAF’s goal is business efficiency. But … efficient with respect to what? Cost? Electrical consumption? Weight loss per hour of exercise? “Efficient” is meaningless without this information. And anyway, efficiency isn’t always what’s most desirable in a business. Effectiveness is the better goal; efficiency is one form of effectiveness among many. Target the wrong goal and the rest really doesn’t matter.

More important (but not most important) is a TOGAF intrinsic: It’s a high overhead approach to business and technical architecture management that ends up fostering rigidity rather than agility.

Documenting the current state is labor intensive. Designing the desired future state is labor intensive. Maintaining the documentation for both as projects finish and IT deploys new or changed information technology is labor intensive.

Meanwhile, attempts to secure funding for architecture remediation generally fail in the competition for budget and staffing with projects whose purpose is delivering direct business value.

But we’ve covered this ground before in KJR. What’s new that makes TOGAF abandonment a 2018 imperative?

TOGAF’s foundation contains a fundamental flaw. We’ve been able to wallpaper over it so far, but won’t be able to ignore it much longer. The flaw: its fixed-layer model.

In the world according to TOGAF, which to be fair has, until today, been quite similar to the world according to KJR, architecture has four layers with well-defined boundaries: the Business layer, Application layer, Data layer, and Technology layer.

But their boundaries are increasingly blurry.

Start with the technology layer. It’s really two distinct layers, infrastructure and platforms.

Infrastructure includes everything applications run on and data are stored in and managed by: facilities; networks; virtualization technology; servers, both physical and virtual; and so on.

Platforms are the tools IT uses to build applications. Except that in many cases the tool IT uses to build an application is an application, not a platform. IT organizations create new capabilities using tools or APIs built into ERP packages, Salesforce, and, for that matter, SharePoint all the time.

And it’s even messier than that, because increasingly, IT doesn’t build applications using just one underlying application as a platform. IT uses an enterprise service bus (ESB) or some equivalent integration technology to create a virtual “source of truth” service out of a collection of “systems of record.”

It builds applications out of these services rather than making direct use of application APIs.

Unless they’re expert systems built out of business rules … and it isn’t remotely clear whether business rules are code or data.

Then there’s intersystem integration, something TOGAF has never represented well. Too bad, because in my experience, integration is where most of the architecture improvement opportunities lie.

Somehow, most companies have still failed to replace their tangle of custom, point-to-point, largely batch, poorly documented and increasingly fragile inter-system interfaces with well-engineered integration. And yet even depicting systems interfaces and integration is pretty much an afterthought for TOGAF and its brethren.

SOA (service oriented architecture) with an ESB provides tools for building engineered integration, but not a methodology for designing it. Documenting the current mess? Even less.

So stop trying to implement TOGAF. Instead, clean up your interface tangle while waiting for the Open Group to address TOGAF’s deficiencies.

And finally …

Resolution #5: Stop making resolutions. Resolutions motivate people to be better than they are by making them feel guilty when they don’t live up to them. But really, don’t you have enough people in your life trying to make you feel guilty without piling on yourself?

# # #

Elsewhere in the news: Check out Bob’s latest in CIO magazine: “How to kill a dead project.” Okay, that isn’t really a resolution. Check it out anyway.

Comments

|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