Reader Feedback On A New IBM i Team Is Needed

August 12, 2013 Timothy Prickett Morgan

Dan:

First, let me say that I agree with the general idea that midrange shops would be better positioned to meet the future with a modern database. I might even be convinced that data-centric development is a good idea, although I personally feel this that we’re already too data centric; locked into the tooling and architectures that existed in the 1980s. But even if we move toward SOA, we aren’t going to get very far without a modern database including RI, triggers, commitment control, stored procedures–the works.

I understand this article was about letting midrangers know how important the modern database is. And as such, it focused on the database over application development, which really needs to advance hand-in-glove with the database if we’re going to do something useful with all those tuples.

What I’m writing about though, is the general tone. All of us have had unique experiences; few of us have travelled exactly the same path to get where we are today. Still, it seems odd to include this ancient. . . motivator “You’re Fired!” in an article about modernizing. As an aside, Hernan Cortes didn’t exactly blaze a trail to modernity. He was the stereotypical Machiavellian, pitting brother against brother, betraying old friends and enslaving vast populations for his own personal gain.

I’ll admit I’ve met my share of ignorance in the RPG community–we aren’t exactly known for being trail blazers. But the overall tone of the piece seemed overly critical of RPG developers. I think it would have been a stronger piece without the digs at the old guard.

I do look forward to future articles on the mechanics of database modernization, especially how Data Studio can interoperate with DB2 for i.

–Buck

Dan:

Dan Cruikshank’s approach is interesting but is not the best solution for organizations with expanding business needs.

The last thing most i-centric IT organizations need are the management complexity, communications challenges, functional silos, and corporate politics created by “special” or “expert” teams. If we need a database team, don’t we need CL and service program teams, too?

Suggesting to management that a crack team of database experts will enable IT to keep pace with business expansion is just that: management crack. Databases are far less complex than application structures, they’re far more stable, and, while important, still represent a subordinate effort in most application development initiatives. After the DB team does their 20 percent of the work on the project, what are they going to do with the rest of their time?

It’s not that there isn’t plenty to do: Many customers have database designs that were flawed when initially implemented, often due to hardware constraints; in my data migration practice, I’ve seen hundreds of them. There’s a need for refactoring the database, not for the creation of a new team. On the other hand, the number of i programmers who don’t understand normalization, or how much they can do with either ALTER TABLE or CHGPF and a source file, is discouraging.

Having a database structure that accurately reflects business operations–read “OLTP”–is absolutely imperative; without it, IT stands little chance of keeping up with a business’s expanding needs. OLAP is a different environment and warrants some consideration. We can agree that database refactoring is one area that intimidates most developers.

But why is a separate team needed? The “single-level store” product line has always been presented as an integrated development platform. So why segregate developers by skill sets? We’re not talking SQL Server or Oracle 11g here! Triggers, cascading deletes, and commitment control may be database technologies but they can have a major impact on the application design and execution; it takes a strong application developer with a good knowledge of database to take advantage of those capabilities. Any experienced application developer knows optimal data structures and application solutions emerge over time as the problem domain is better understood and as customers refines their needs based on changing business conditions and priorities.

A far superior approach is to adopt Agile (Scrum) development practices, where self-organizing, self-disciplined, and cross-functional teams regularly deliver new and updated applications with features that support business-prioritized needs. Database architecture and design evolve “just in time” as needs, features, and requirements are implemented and deployed; no time is wasted on “speculative” work. Agile’s acceptance of refactoring helps keep the solution on target and controls the technical debt burden. Agile teams work closely with product owners on a daily basis and have the interests of their employer at heart.

Agile does scale for larger organizations, and there may be a combination of feature, component, and architecture teams working closely to ensure maximum value is being delivered. All development effort becomes “remote” or “distributed” at some point, if for no other reason that there’s no space in the office that will accommodate the full team. Due to the high-bandwidth communications required by Agile and the excellent results provided by good Agile teams, outsourcing is not a good financial or operation decision.

Data-centricity is not the “droid you’re looking for.” Database architecture and design are extremely important but they’re only tactics in the larger battle of supporting the business. An IT project portfolio with direct traceability to business strategies and a business-owned and business-prioritized product backlog are far more critical to enterprise success. Data centricity will emerge as an attribute–a non-functional requirement–when it serves the needs of the business.

–Reeve

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search