Best Practices in IT

Learn, Practice, Improve

Most of my IT career has been as a consultant and a manger of consultants. Over the years I have established some patterns to follow that I find helpful in making projects and technology easier in the long run. I sometimes share these in mentoring sessions and have heard often enough “you should write that down” where I started to.

I am still writing these concepts down, and while they originate from a consulting perspective they translate to every day practices beyond consulting.

At the time of this writing (not reflected by the pub date), I am re-vamping this site. Part of the update is moving this content from a standard page to a category page. The navigation will change to reflect that when it is either complete or well along.

Project Team

Failure to plan communications is communicating a plan to miscommunicate

Scott S NelsonLeave a comment

Most project charters include a communication plan, and it generally consists of who to communicate what to. What is often missing is the how, which is why many teams find themselves with endless email chains where the subject stopped reflecting the content a dozen messages down the thread.

Many enterprises offer multiple platforms, such as Slack, Teams, SharePoint, Confluence, Jira, ADO, etc. If there is a choice, determine how the team will most efficiently interact and then pick the tool that has the best features supporting those interactions. If there isn’t a choice (such as when a company may have several tools but a department only has one), be sure to keep some key communication and collaboration practices in mind as you plan its usage.

Taxonomy

Group topics in an intuitive manner. What is intuitive generally versus only for insiders can be different. If the team membership will fluctuate frequently, opt for intuitive for someone who needs to be productive quickly with little help. Long-term teams should evolve the taxonomy over time to foster productivity.

Formatting

We all get busy and skim our in box or project sites looking for what jumps out at us. Consistent formatting can help. Have predefined prefixes such as “ACTION REQUIRED:” or “No Response Necessary:” can help people see what is important and prioritize reading and responding. The range of formats can be very broad, so a full list is not appropriate here.

Read Me

The best of plans do not survive the first release. The taxonomy may fall out of date. Determine the most common entry point to the team collaboration and communication platform and post and pint a Read Me that explain the purpose of the team, the organization of the platform, and who to contact for help by topic.

Channels

Often a project will have multiple channels: The project management tool, the wiki, and IM client, email (sparingly). The team should decide which channel to use for what and gently remind people who use the wrong channel where the appropriate channel is and why.

If you found this interesting, please share.

Is IT a cost center or profit center?

Scott S NelsonLeave a comment

Quick summary: Transforming IT from a cost center to a profit center starts with more strategic business decisions concerning technology.

There are parts of IT that are costs, such as vendor-provided platforms, and this may confuse some into lumping all of IT into the cost center bucket. IT can (and should) be a profit center. Efficient IT can improve profit margins and growth. It is the business practices and decisions to treat IT as a cost center that eventually turn it into one.

Just as applications are useless without users, Enterprise IT that doesn’t provide value eventually won’t have an Enterprise to provide value for. What is often forgotten is that business capabilities are only as reliable as the processes that support them, including Enterprise IT processes. Many may believe that technology companies are the fastest and strongest in the market because they are more valuable, and I believe they are more valuable because they understand the value of technology and treat it as an investment rather than a cost of doing business.

Comparing Apple™ to apples

The difference in the nature of products fosters the confusion. A widget (or apple, to clarify the subheading) company that has a failure in the manufacturing process can go bankrupt, whereas a software company that has a defect can just issue a patch, ergo, issues with software are less important than issues with other enterprise activities. The misconception is that the software product is the same as the enterprise software that distributes it or the systems that communicate with customers. If that enterprise software fails for either the software company or the widget company, they are going to have a bad quarter (or worse). Tech companies know this, and it is why so many that run at a loss for a long time are later the biggest players. A deeper look into companies not considered as technology companies will show that the highly successful ones treat their Enterprise IT systems as if they were technology companies.

A clear indication of a company misunderstanding the value of their enterprise systems is the accumulation of technical debt. Technical debt is the result of Enterprise IT taking shortcuts to meet business objectives. For widget companies, or even widget service companies, this seems like a good trade off, because widgets are more important than enterprise systems to a widget-based company. Like any debt, technical debt grows exponentially when the principle is not paid down. True, that is not how math works, but it is how debt works, because the same attitude towards debt that focuses on interest payments and not the principle also tends to acquire more debt in other areas—or attempts to address the debt by restructuring it into new debt that is larger because there is a cost to the restructuring.

Getting interested in debt

The debt is a result of treating shareholders as Enterprise IT stakeholders. The business is the stakeholder, and while the shareholder may be a stakeholder in the business, it is the responsibility of the business to do what is best for shareholders by seeking ways to increase value in a sustainable manner. Enterprises that are spending money on paying loan interest are not giving that money back to the business and the shareholders. Eventually, this will erode share value.

The cost of technical debt is that expanding business capabilities takes longer or costs more or both. Unmanaged technical debt reduces quarterly earning capabilities, sometimes exponentially in relationship to value realized. Eventually, the debt becomes “real” enough that the business takes notice and invests in dealing with it…or an organization with a much lower level of technical debt takes over the company and enjoys the profits of applying their own solid, stable infrastructure to selling widgets in addition to their other successful enterprises.

“Lies, damned lies, and statistics”

Another perspective that leads to technical debt and higher IT costs is quarterly reporting. IT in the profit column puts a focus on ROI and a culture of seeking efficiency in providing new and improved features. If IT is in the cost column, cutting costs sounds good on the quarterly report, but what reduces IT spending in one quarter will increase the cost in a future quarter, both in maintenance and impact to further growth initiatives. Technical debt is less of a metaphor than an understanding of the true monetary value of IT.

Some may take the viewpoint that the need to update IT periodically is an argument for it to be considered a cost center. That need is (generally) driven by two things: the accumulation of technical debt making it cheaper to replace, or an improvement in the technology that makes an update even more profitable. To be fair, this misunderstanding is exacerbated because there are many initiatives that claim to be driven by the latter when the root motivation is the former.

Bottom line

Thinking of shareholders as IT stakeholders is a recipe for fragility. If technology is not improving profitability, then it either needs to be updated or discarded for the right technology. The only way to cut costs in the long term is to invest in reversing technical debt from previous quarters and reap the rewards in next quarters.

Originally published at https://logic2020.com/insight/it-cost-center-or-profit-center/

If you found this interesting, please share.
Ready, fire, aim

Agile is not Ready, Fire, Aim

Scott S NelsonLeave a comment

(Disclaimer: this article is not about what Agile is, the term is used only for blatant marketing purposes. Some principles were violated in the writing of this post)

A colleague of mine recently said something to the effect of “the goal of agile is faster delivery”.  This is a common misconception fostered by the improved velocity that agile teams can achieve in the context of enhancing software with new or improved features. The goal of agile is higher quality software, where quality is defined as meeting the intended functionality in a reliable manner. (lots of paraphrasing there, so please don’t flame me about accuracy). Another root of this misconception is that people who do not participate in agile projects (sometimes referred to as chickens) want agile to be about time-to-market (I’m working on a longer rant on that topic alone). Just like some people want agile to eliminate the need for planning and documentation, not be because these things are not critical (apologies for the double negative), but because they are tedious. They are certainly not mindful, because one focuses on the past and the other on the future, and we all want our features right now. Agile without planning and documentation leads to technical debt (something I grumbled about recently, with more to come).

Technical debt is the driver behind this particular rant, as I recently observed the creation of an equivalent jumbo mortgage with an early balloon payment due. In the same recent article linked earlier I mentioned how sometimes a platform migration is driven by a desire to get out of unacknowledged tech debt. In this instance, I witnessed the debt being incurred as a result of the migration. Specifically, the approach was taken to manually migrate data that was in immediate use while configuring the application without documentation in order to get into production as quickly as possible (the root cause of most tech debt). The idea was to migrate the rest of the data later. This migration, like many these days, was from one SaaS to another. The secret to a maintainable and extensible SaaS application is including flex fields in the data model. These are fields that have no pre-defined purpose so that customers can use them for customization and the vendor can avoid the hairball that results from customizing for each customer. The downside to this data model is that if the customer changes default labels and makes heavy use of the flex fields without documenting all of these changes, the data migration effort increases several-fold.

So, here is a real-world example of the impact of technical debt in a compressed timeline that is easy to follow: Short cuts were taken to quickly “realize value” from a new platform, and then to fully taken advantage of the platform subsequent efforts are increased, resulting in a much higher total cost and longer timeline to completion to get that short term win. None of this is the result of bad people or malicious intent, in fact, quite the opposite. It is the result of a “modern” business culture that has evolved to focus on quarterly earnings. It also explains why businesses that really want to innovate either do so before their IPO or go private to get back on track. It’s not because software can’t be done right in a standard corporate structure, but that “Continuous attention to technical excellence and good design enhances agility”.

If you found this interesting, please share.
IT Design

(Some) Best Practices in Design

Scott S NelsonLeave a comment

Note: This is far from an exhaustive list, and will be updated occasionally to reflect that.

Design First

Always design first. Even if it is an agile project with an aggressive timeline, a clear understanding of what your solution will look like and the steps to get there will make the path easier to get to. Designing first is the opportunity to think through what you will be doing and recognize potential issues in advance. Often when design issues show up late they are dealt with as code flaws rather than design flaws, taking longer to correct and often leaving the design issue in the “fixed” result.

When I can recall the exact wording and attribution I will update this post…meanwhile, not defining an architecture is an architecture. Some refer to it as a Big Ball of Mud. I particularly like Gregor Hohpe’s many takes on this choice. Here is a link to an older-but-still-accurate blog post of his.

Developers need to Design, too

Your design can be as simple as stubbing out all of your classes before developing them. This way, issues that were missed during the design phase are more likely to be discovered earlier, before they become harder to fix.

Test-Driven Development is another approach to catch issues early on.

Insist on Design Review

Have a technical lead or peer review your design. The additional perspective is always helpful, either by validating that your approach is sound or questioning choices and reviewing options found by a fresh set of eyes.

Environment Variables

Environment variables should be maintained in the environment. Placing these variables in components where they must be updated between environments reduces the value of such variables and increases the chance of errors when migrating deployments between environments.

Balance Early Adoption with Out-of-Date

Going first in a presentation is brave. Being first to apply a new technology in an enterprise is always risky, and those risks must be seriously weighed beyond the “cool factor” of being an early adopter. Once you have committed to early adoption, mitigate risk with thorough testing and following any active communities taking the same journey.

Because of the frequent and rapid changes in technology, the familiar approach is not always the safest. Libraries, functions, features and patterns currently in use at your enterprise may be heading toward deprecation and retirement. With vendor products, especially cloud platforms, a newer, better approach could be available that is solid and well-tested (depending on the vendor, YMMV). Always check for newer alternatives before committing to a solution, and weigh the alternatives for fit both from a functional perspective and maintenance implications. And…

Don’t Trust, Verify

Vendor claims are written by the marketing team, not the development or support teams. If a vendor states that Product X provides feature Y, validate that it does and that it does it in a way that supports your design before committing to it.

DevOps

Yes, DevOps is a category unto itself, and it also needs to be considered during the design phase. Retrofitting DevOps practices is often difficult. For greenfield projects, prepare a detailed recommendation on the benefits of DevOps for the application and the steps necessary to implement and maintain. For enhancement projects, review the technology landscape for potential and recommend accordingly.

Test Automation Design

Not all applications are the same, so using the same tools and patterns for all applications won’t work. That isn’t to say they can’t be reused across applications. What is important is not to assume fit for purpose. At a minimum, review the current state of the are for the tools you are familiar with, who their competitors are, and then try things yourself before believing any hype. This review should be repeated regularly once the test stack is designed to maintain relevance.

If you found this interesting, please share.

Yet Another Tech Debt Post

Scott S NelsonLeave a comment

Quick summary: Technical debt is the elephant in the room … the same elephant that the blind men were curious about. Understand how perspective contributes to and can resolve tech debt.

Logic20/20 has been involved in many platform migrations and technology refreshes. While there are myriad reasons to make such a major shift, the three key drivers are:

  • Gaining new capabilities
  • Increasing time to market
  • Reducing costs

Most other reasons will fit into one of those three, and usually it is more than just one of the three. All three are valid and valuable reasons to commit what is usually a large amount of resources to achieve. What is seldom acknowledged is that the initial motivation for the expense is to deal with technical debt.

Boom. Yes, that is a big statement. Let me unpack it a bit. Most new capabilities can be added through adapters or integration. Time to market can be severely hampered by technical debt, as can the costs associated with development and maintenance. That isn’t to say that upgrades and technology shifts aren’t necessary, only that the tipping point frequently comes from the accumulation of technical debt.

Once the transition to a new platform (be it an upgrade or vendor change) is complete, what follows depends on whether the influence of technical debt was acknowledged as part of the effort. Organizations that utilize processes, policies, and governance to manage technical debt can find that their ROI from the project will more than justify the expense. Those that do not recognize the contribution of technical debt to the problems with the old way of doing things and believe the issues were only within the platform will find that they will be ready for another migration in as little as one year.

The thing about technical debt is that it is not always recognized because of the different perspectives that result in its accumulation. I think of these as What, Why, and How. My experience is that the order of how these perspectives are realized determines the organization’s maturity in relation to managing technical debt. It is when they are recognized in the reverse order that it takes longer to reach a point where the organization is managing technical debt.

How is a technical aspect. It is the use of architecture, design, and implementation solutions that focused on the immediate need over the long-term solutions. At the time the decisions are made that lead to technical debt, the technical team usually knows it is happening and has hopes (if not actual expectations) to address the debt in later releases.

Why is a business problem, and is also more a series of questions than a statement. Was the initial debt incurred by informed decisions? Is the increasing debt the result of planned obsolescence or not knowing the impact? Are they even aware that their drive for business capabilities resulted in technical debt? The diagram at the end of Martin Fowler’s TechnicalDebtQuadrant post is the clearest representation of what leads to technical debt. Frequently the types of conversations necessary to make informed decisions don’t happen because technology and business make assumptions about viewpoints that are generally inaccurate. Communication is always a key factor to enterprise success.

What is a universal, once it is recognized either by the How or the Why: It is architecture and design issues that impede progress through time spent on maintenance and work-arounds. The How cannot change the What unless there is an important Why. In other words, the debt will not be reduced by technical teams unless there is a good reason for the business to pay for it.

The first step is reducing or eliminating the accumulation of technical debt. The second step is to determine how much focu$ will be dedicated to each release to reduce the technical debt. In most cases, this should be a gradual process of adopting new patterns and spending some time in each release refactoring what is related to the release. In some cases, the impact is so pervasive that either an entire release needs to be focused on refactoring or one team needs to be dedicated to it for one or more releases until is manageable again. Whereas most technical debt has a common cause, the path out of technical debt needs to be tailored to the enterprise and the system to be successful.

Originally publihsed at https://www.logic2020.com/insight/tactical/technical-debt-what-why-and-how

If you found this interesting, please share.