All Posts in Technology

|In: App Dev Methodologies|Last Updated:

In the beginning there was dBase II, designated “II” by Ashton-Tate, its publisher, to convey a level of maturity beyond its actual virtues. It was followed in quick succession by Paradox, Delphi, and Microsoft Access, all of which overcame most of dBase II’s (and III’s, and especially IV’s) numerous limitations.

Compared to traditional programming languages these platforms increased developer productivity by approximately 10,000% compared to traditional COBOL coding – they let me get about a day’s worth of COBOL coding in five minutes or so.

This history was current events more than twenty years ago and yet IT shops still write code and enshrine the practice with various methodologies (Scrum, Kanban, DevOps, add-your-favorite-here) intended to improve IT’s overall app dev effectiveness.

Speaking of deja vu, the pundits who track such things write about no-code/low-code (NC/LC) development environments as if they’re something new and different – vuja de, like nothing they’ve seen before – when in fact they offer little their 1990s-vintage predecessors weren’t capable of way back when.

Should NCLC be in your future? Gartner says yes, predicting that by 2024, “… low-code application development will be responsible for more than 65% of application development activity.”

They make it so easy … to nitpick, is that 65% of all lines of code that will be produced using No Code tools? Probably not, as No Code tools by definition produce no code.

Function points? Maybe, except that nobody uses function points any more.

Probably, Gartner means 65% of all developer hours will be spent using NC/LC tools.

Which is simply wrong, on the grounds that most IT shops license when they can and only build when they have to. In my unscientific experience, looking at total application functionality as the metric, maybe 75% comes from COTS implementations (commercial, off-the-shelf software, which includes but isn’t limited to SaaS packages). Maybe 25% comes from in-house-developed custom applications, and that’s being generous.

As NC/LC platforms don’t touch COTS/SaaS functionality, it’s doubtful that work on 25% of the application portfolio can occupy 65% of all developer hours.

But I digress. The question isn’t whether Gartner has done it again. The question is how much attention IT should pay to this platform category.

Answer: If coding and unit testing are enough of a development bottleneck to care about, then yes. When it comes to optimizing any function, removing bottlenecks is generally a good idea.

Second answer: If in your company DIY application development is a source of a lot of application functionality, then selecting an NC/LC standard, integrating it with your application portfolio’s systems-of-record APIs, and providing training in its use will save everyone involved from a lot of headaches, while removing a source of friction and conflict between IT and the rest of the business.

Third answer: Most COTS/SaaS applications have some sort of no-code or low-code toolkit built into them. These should be IT’s starting point for moving in the NC/LC direction, and for that matter for any new application functionality.

Bob’s last word: It’s easy to fall into the trap of answering the question someone asks. “Are NC/LC tools useful and ready for prime time?” is an example, and shows why Dr. Yeahbut makes frequent appearances in this space.

The answer to the question is, in fact, “Yeah, but.” NC/LC development should, I think, be part of the IT app dev toolkit. But mastering the tools needed to integrate, configure, enhance, and extend the company’s COTS application suites has, for most IT organizations, far more impact on overall IT app dev effectiveness than anything in the way of app dev tools.

Bob’s sales pitch: As a member of the KJR community you might enjoy my most recent contribution to CIO.com, and a podcast I was interviewed for.

The CIO.com article is titled “The hard truth about business-IT alignment.” You’ll find it here.

The interview was for Greg Mader’s Open and Resilient podcast and covered a number of KJR sorts of topics. You’ll find it here.

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