Too many organizations, perhaps most, struggle with the delivery of applications that provide a true fit-to-business, while at the same time presenting a ready-state for efficient maintenance by IT staff.

Even in the happy event of a solid near-term fit, there lurk unseen liabilities: Too often, an application comprises code structure that undermines ease of maintenance; defies ease of testing and upgrade; short-changes endpoint flexibility (for points known, unknown, evolving and/or emerging); and may even defeat continuous refinement. The result? Code and allied applications that are heavy in “technical debt.” As time goes by, an organization’s ITteams can spend exorbitant time tearing apart, re-engineering, or re-building from scratch an application that should have been engineered with a bit more structural vision and adaptability in the first place. The focus for advancing any application’s longevity and service to the present and future should be in upgrading/updating its functional and non-functional requirements, not accommodating future impacts to its architecture due to poor fundamental core-code construct(s).

For organizations struggling with ongoing problems associated with cumbersome “lurches” forward involving poorly defined and conducted projects and associated, diminished, deliveries (either over-budget, past-due, involving poor-fits, or all three), and the irritation of an increasingly rapid cycle of modernizing or replacing legacy systems (and really, anything is a “legacy” waiting to happen), a firmer footing is available. How to start?

An initial survey has to be made of the organization’s teams. In recent years, much ado has been made regarding the problems of “silo’d” teams: at the extreme, groups of people laboring in some measure of ignorance of other parallel and even competing endeavors. But beyond inefficiencies and errors, IT teams that are too discretionized behind their own “walls” may come to view other teams as competitors: competition for budget; for management favor; for prestige. A softening of the traditional Organization Chart is a hallmark of the “Leading Organization” over the “Traditional Organization.” With the softening comes a new appreciation for the organization whole as a team: One with a common mission and associated rewards: Better business, better service to clients, better morale for staff… Better code? Better applications? Yes.

A new affinity between teams allows for more trust and knowledge share. Members from various teams are more amendable to “pitching in” with advice and even an extra hand when time and demands permit. But as importantly, a new commonality between all IT members manifests for the purpose of building better code structure. Any department or team will harbor individuals of varying general strengths (and weaknesses), both technical and non-technical. What we will desire, foster, and share will be those members who have the strongest understanding of best and evolving code structure for present and future.

A strong focus on code structure has to place emphasis beyond the delivered capability for what any user sees. Structure has to support a lifecycle: Ongoing management of code that is easily developed, tested, and deployed into a live environment; code that is rapid in its deployment; code that has appropriate diagnostics; and documentation. Leading organizations in these regards ensure that code has appropriate structures in which to hang code –team structures, team practices, and disciplined code structures.

Bring your teams together for a discussion of ideas involving code structure: Think “refactoring”… then think “what has past refactoring taught us?” Subsequently, employ “pre-factoring” in the design of code. As importantly, have this new team affinity yield an understanding for how various business systems and apps can utilize code and structures to help the overall interdependency of so-called “independent” systems. Leverage intelligent code structure at the outset, share the best ideas amongst your teams (through the affinity of everyone by virtue of that soft Org Chart), and start building better, more efficient, and more efficiently managed, code. Not only are we avoiding “technical debt” here, we are mounting “technical assets” in the form of better code, code that is more easily managed, and with less central peril of obsolescence and future legacy overhead.

Given all of the (evolving) devices as endpoints today, and knowing more are undoubtedly to come, we now have teams, understandings, and practices that are much more likely to yield code, and applications, that serve an explosion of device types, form factors, operating systems (and versions), patches, and variations. Given the ubiquitous nature of the Cloud, virtually everything must be situation-able to any endpoint; i.e., any device and associated enablements/uses. Further, applications should make accommodation to user “attributes” – Who is the user; what is their level of sophistication; what is their level of user-education; have they been here before; what is their authority; what do they want to do; what do they need to do?… and so forth.

Share those considerations with teams as well. Bring all ideas and real world requirements to your structure of better code and applications.