On Technical Debt http://www.ontechnicaldebt.com Online Community Wed, 22 Jul 2015 15:25:12 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.3 Technical Debt, Transparency, and the Iron Triangle of Development http://www.ontechnicaldebt.com/uncategorized/technical-debt-transparency-and-the-iron-triangle-of-development/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-transparency-and-the-iron-triangle-of-development/#comments Tue, 21 Jul 2015 13:30:07 +0000 http://www.ontechnicaldebt.com/?p=3564 read more]]> There are a lot of blog posts floating around out there that try to talk about technical debt in a new and interesting way. Few actually achieve this goal. There’s not much you can add to a concept that has been explained over and over again. This podcast with Microsoft veteran exec, Bill Bliss, gives a talk on technical debt that although not revolutionary, touches on some ideas about technical debt that are enlightening.

1. No matter what your company does, if you are relying heavily on software for your product’s success you are a software development company.

More and more we are beginning to see companies, which rely heavily on technology for their offerings, being managed by non-technical stakeholders. This has become the norm, but it causes a problem because these non-techies often forget that their businesses, at their core, are software development companies. When you forget this, you tend to mismanage your technical team: resulting in unrealistic deadlines and mountains of technical debt.

2. Technical and non-technical stakeholders lack of proper communication leads to a development black box (be aware of the iron triangle of development).

The barrier between technical and non technical people is an issue of language. Business and technical sides of an organization are unable to communicate their needs and limits effectively. Because of this, the technical side of a company ends up being a black box where non-technical leaders don’t understand their development teams and simply expect them to perform. This leads to an untenable relationship where development teams are expected to do things fast, cheap, and well.

The iron triangle of development says that this is impossible. You can do two of these things at once (fast & cheap, fast & well,  or cheap & well) at the expense of one. But, if you consistently build code quick and cheap – you will be creating technical debt.

3. Once you have technical debt, if you can’t communicate what’s so bad about it you will probably keep piling it on.

Keeping an eye on your technical debt can be incredibly difficult when you can’t communicate the impact it has on your operations. The underlying issue is that technical debt manifests itself, in the eyes of business stakeholders, as a tax. But those working on the technical-end feel the burden of technical debt heavily. It can manifest itself in scripts that take over an hour to run, breakages in code, and a brittle code base that makes adding features time consuming and demoralizing.

Communicating technical debt in terms of the cost/benefit of fixing or not fixing those areas with debt, is the best way to resolve the lack of understanding between the non-technical and technical dichotomy of the business. Once there is such an understanding, steps can be taken to reduce technical debt.

4. The ‘big rewrite’ can be a big waste of time.

The urge is often to rewrite a section that is heavily burdened with technical debt. This is a bit of a paradox, since once a section of code base reaches the point where a rewrite is warranted, it is probably too complex to be discoverable and be able to rewrite. In other words, the code that needs to be rewritten is so entrenched in the code base that rewriting it would be like changing a tire while the car is still moving. Ultimately, if the code does the job it is intended to do then keeping it is the best decision. If the decision has been made to rewrite, an API has to be built in order to wrap the code and make rewriting easier.

5. Be weary of open source, it won’t solve all your problems and may create new ones.

It must be kept in mind that technical debt is not always the result of bad architectural decisions, but the result of changing technological needs. Because of uncertain needs, businesses have started to turn to open source software – which creates another black box for business stakeholders in relation to the technology they use. A framework for decision making needs to be implemented when deciding what to build and what to buy. Buying packaged software can be useful, but also creates uncertainty on the quality of code within the opaque package. Transparency is always helpful when trying to manage technical debt and the quality of your software, but the expediency of buying something pre-made is also a benefit to business operations. Depending on what problem(s) you are trying to address lies the answer to whether open source is right for your business. If you are simply looking for 1 feature, then building it yourself makes more sense.

Ultimately, managing your technology assets needs to be a transparent and well documented process. Understanding between the business and technical sides of the organization need to be improved and made a priority because the success of keeping a clean code base depends on it.

To listen to the full podcast visit here.

http://www.ontechnicaldebt.com/uncategorized/technical-debt-transparency-and-the-iron-triangle-of-development/feed/ 0
How the Public Sector is Dealing with their Legacy Systems http://www.ontechnicaldebt.com/uncategorized/3558/ http://www.ontechnicaldebt.com/uncategorized/3558/#comments Mon, 20 Jul 2015 14:44:35 +0000 http://www.ontechnicaldebt.com/?p=3558 read more]]> There’s a new wind blowing in technology, specifically in the public sector, on how to handle the crossroads between systems that have been around for decades and upgrading to the latest wave of new technologies.

While this is a concern in every organization where technology is central to their functions (which in this day and age is every single one) – it’s a concern that resonates strongly in the public sector. Government agencies are often allergic to risk, which makes their speed and level of innovation slow when compared to private enterprises that jump on the chance to be first-to-market. However, there’s been a shift within government (exemplified by the Department of Housing and Urban Development) where CIOs are beginning to focus on modernizing decades old legacy systems. Such a transformation requires intense organizational scrutiny and oversight.

At the Dept. of Housing and Urban Development there has been a large scale move to consolidate or in-source many of its core systems. In 2014 they began to in-source their finance management and administrative functions to the department of treasury. This would help the agency to pay down its technical debt by narrowing the complexity of their systems while also removing barriers of scale for future development.

This is the best case scenario, where consolidating your systems reduces redundancies, dead code, and inefficient processes. But for many, solving the problem of technical debt in legacy systems is more of an overhaul process. Consolidation, is usually a safer bet for public sector organizations because it doesn’t add innovation but merely streamlines current processes. But we’re reaching a point where that just doesn’t work anymore.

Look to the recent events at the OPM – where 21 million past and present federal employees social security and other personal information where stolen – as an example of halted innovation that had a serious backlash. At the OPM, over a period of 7 years they received warnings that their systems were falling behind on security measures and on resources to keep their applications healthy. They failed to do heed these warnings and now there’s a long list of evidence demonstrating their incompetence. The culmination of all these failures? A severe data breach and the theft of millions of records.

This is the extreme case, but it exemplifies how handling innovation and modernization can cause severe problems if its not attended to promptly. This is what is so often preached in our posts on technical debt: if you don’t deal with it while its small and manageable, it will reach a point where things will go very very wrong.

To read the post on public sector technical modernization, click here.

http://www.ontechnicaldebt.com/uncategorized/3558/feed/ 0
The Short Memory of Lessons Learned in Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-short-memory-of-lessons-learned-in-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-short-memory-of-lessons-learned-in-technical-debt/#comments Wed, 15 Jul 2015 15:53:52 +0000 http://www.ontechnicaldebt.com/?p=3552 read more]]> Looking at the events of last week – the technical freezes at the New York Stock Exchange, United Airlines, and the Wall Street Journal – we’re starting to see the pretty startling effects cobbled together systems and technical debt.

When the WSJ’s website is offline for about an hour due to a technical issue  – we are annoyed

When planes are grounded across the country due to a network issue at United Airlines – we are baffled.

When the NYSE is unable to trade for about 4 hours due to a computer glitch – we start to see a trend.

Technology is often taken for granted, and in many posts we’ve published this has been touched upon. Whether it means explaining to business stakeholders the importance of setting aside resources to refactor code, or making them understand that building software quick and dirty can have severe consequences. All this points to a general lack of understanding that software deteriorates overtime and requires constant attention.

Technical debt is easy to accumulate in a fast paced business environment. Most companies now want to provide the newest and most innovative technological offerings to their customers. This means building fast and often times throwing caution to the wind. Was this the case last Wednesday with the series of technical failures that occurred?

Well, they were internally created failures. At the NYSE the issue was blamed on a “computer glitch”. At UAL their network went down due to a faulty router. In other words the two issues were caused by buggy code. This is a sign of poor development.

What a wake-up call for any organization when you realize that one defect can cause your system, and ultimately your business, to shut down for hours. The costs of such a failure are great – especially when they affect the customer experience. Therefore, it can be assumed after an event like this that the NYSE and UAL are taking all the steps necessary to address and prevent the problem that caused their poor performance. But let me further stress: there is the danger that they only address the one problem that caused their most recent failure.

Again, this is all an assumption, but much has been said and written on the fact that many organizations have a short memory span when it comes to building software that is structurally sound and stable. These standards usually fall under the radar and are replaced by a pressure to meet stringent deadlines. Ultimately, what I am asking is that we not forget that software comes with an expiration date. Code can go bad. Especially when it was built poorly to begin with and is meshed together with old brittle systems prone to breakages.

Many systems in large organizations are highly complex due to years of trying to keep up with innovation. The technical outages of last week are simply a reminder of the consequences of unbridled debt.

Don’t forget that these outages are not isolated incidents, but a possibility for any organization that’s played quick and dirty with its code.

http://www.ontechnicaldebt.com/uncategorized/the-short-memory-of-lessons-learned-in-technical-debt/feed/ 0
Technical Debt is not only a “Technical” Problem http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-not-only-a-technical-problem/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-not-only-a-technical-problem/#comments Mon, 06 Jul 2015 17:05:21 +0000 http://www.ontechnicaldebt.com/?p=3540 read more]]> A question that is not asked often, and less often answered, about technical debt is: who must you pay and how?

This question is vital to answer – because it also gives you an idea of who you are borrowing from when you take on technical debt. Often times technical debt analyses miss this critical part of the financial metaphor. So who are you borrowing from when you incur technical debt? The assumption is that you’re borrowing from yourself: this means that you’ve accumulated capital and borrow against your own reserves. Paying back this debt means putting funds back into your savings. This is the best way to borrow money. However, what actually happens is that future capital is placed as collateral for the loan you take when you build a tech debt ridden feature.

When code that has technical debt is released, revenue is generated that can’t be paid for yet. In this case, you aren’t borrowing from yourself because you don’t actually have the funds to spend from. Acknowledging this leads to a better understanding of the full ramifications of technical debt. The consequences of this debt don’t solely extend to the technical side of business. For example, when this code is released and provides a service that is built in a compromised way the marketing team with have to message the feature accordingly. Sales teams have to qualify leads so  that customers are not frustrated with a product that does not work as it is said to. Product management will have to understand that every new release will be expanding on a poorly built base and will be more expensive with each release. Overall, the organization will have a flimsy strategic advantage because they have a unique feature that is built in a compromised fashion – their offering will have to be qualified and enthusiasm for the product will be watered down.

When building with technical debt its effects don’t stop at the technical level. The technical results of this debt, due to quick and dirty work, means a product that is vulnerable to failure and to not performing properly. This vulnerability infects every other part of the organization.

However, technical debt is often times the only way to get ahead. Therefore, when deciding to build with technical debt there need to be clear terms set for the loan: business leaders should be aware of what debt is being taken on and a plan of action for tracking it and paying it off needs to be implemented. The reason for involving business leaders is because the problem of technical debt is not insulated from the rest of a company – in fact by borrowing from future capital it involves the organizations very ability to bring in revenue. Therefore, if  it is not explained properly to business leaders they will not understand the necessity of paying off that debt. This leads to a lack of resources set aside to refactor and restructure debt.

It’s when organizations underestimate and don’t understand technical debt that they run into trouble.

To read the full post visit here.

http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-not-only-a-technical-problem/feed/ 0
The US Navy Pays the Price for Faltering on Innovation http://www.ontechnicaldebt.com/uncategorized/the-u-s-navy-pays-the-price-for-faltering-on-innovation/ http://www.ontechnicaldebt.com/uncategorized/the-u-s-navy-pays-the-price-for-faltering-on-innovation/#comments Wed, 24 Jun 2015 18:11:12 +0000 http://www.ontechnicaldebt.com/?p=3526 read more]]> About two weeks ago, we posted an article on the pressures of digital transformation and the technical debt that results from trying to keep up with innovation. We’re seeing those same pressures as the US Navy Warfare Systems Command struggles to phase out its reliance on obsolete Microsoft products. The US Navy is paying Microsoft millions of dollars to support about 100,000 computers that still use Windows XP, Office 2003, and Exchange 2003.

The retention of these programs, which Microsoft hasn’t supported for years in the commercial sector, demonstrates that some organizations just can’t keep up with the rapid pace of technology change. As we mentioned in our previous post, “the transformation businesses need to undergo in order to keep up to date with current technology, combined with day-to-day processes, amounts to a mountain of technical debt that can be nearly impossible to get over.”

Technical debt can often result in security vulnerabilities and failures – which is understandably not favorable for the US Navy. This may explain why it has taken almost three years for the Navy to wean itself from these systems, which affect critical command and control systems. A Navy spokesperson stated that without the paid support from Microsoft “…vulnerabilities to these systems will be discovered, with no patches to protect the systems.”

It is clear why the Navy is hesitant to try and play catch up, in a quick and dirty way, while phasing out its legacy systems. It also illuminates the difficulties other organizations face under similar situations, when they aren’t a government agency with the funds to keep using obsolete software, and must react to their more nimble competitors.

Government agencies prefer to have a tight hold on the technologies they work with, slowing down their adoption of modern alternatives. However, keeping an obsolete system out of a concern for security is contradictory. XP is not an adequate option to protect networks from the security threats of today and paints the Navy as a bloated government organization unable to change efficiently.  Other commercial organizations do not have the same stringent compliance rules to deal with when it comes to their technologies, allowing them to change faster and prepare for future threats.

So, how do you address such a problem? It really boils down to flexibility and preparedness for change within your organization – a common factor when discussing building software that is able to adapt to technology’s certain and constantly evolving innovation. In order to avoid continually facing the hardships of replacing antiquated hardware and software, you can start creating a plan to manage innovation. This will be helpful not only by guaranteeing quicker adaptation to the improved technologies, but also in protecting your organization from failures that result from old creaky systems.

To read the full article on the Navy’s payments to Microsoft click here.

http://www.ontechnicaldebt.com/uncategorized/the-u-s-navy-pays-the-price-for-faltering-on-innovation/feed/ 0
When Technical Debt Is Better Than Clean Code http://www.ontechnicaldebt.com/uncategorized/when-technical-debt-is-better-than-clean-code/ http://www.ontechnicaldebt.com/uncategorized/when-technical-debt-is-better-than-clean-code/#comments Mon, 22 Jun 2015 17:55:17 +0000 http://www.ontechnicaldebt.com/?p=3517 read more]]> It is often mentioned, when reading about technical debt, that taking on debt can be appropriate and even beneficial in certain situations. However, what are the criteria that can be used to define which scenario is good for technical debt and which is not? This post gives a good answer to that question. There are two times when it is appropriate to incur debt: when creating a new feature or entering a new market.

In order to decide whether or not to take on technical debt, there are four factors that should be considered:

  1. Value of early feedback
  2. Cost of debt
  3. Cost of errors
  4. Likelihood of errors

The optimal situation to incur technical debt would be one where there is a high value to early feedback, when what is being built is isolated from the rest of the system (therefore making the cost of debt low), when the cost of errors is low due to a small number of users, and when the likelihood of these errors is low. The two scenarios mentioned above consistently meet this criteria.

The first scenario is when there is an idea for feature that could present value to users – it may then be worth taking on debt to deliver this value to users. Delivering a feature early also has the added benefit of receiving quicker feedback: if the feature is a valued addition it makes sense to take the time to pay back the debt, but if the feature does not do much for the user it can be removed from the code and effectively erase the technical debt. A quick and dirty built feature is beneficial in such a case because the probability of it being kept or thrown out is unknown. Therefore, spending time from the start of development to create clean feature is not necessarily advantageous.

The second scenario where incurring technical debt is acceptable, if not helpful, would be when working to enter a new market. For example, when developing a product with a start-up company, the first round of development should be focused on producing something that helps support the business model. This means that what is being built does not need to meet the standard of release to users – there is an expectation that the product evolve overtime and large segments of the prototype may be thrown out along with its technical debt. The benefit of building something that is debt ridden, in this case, is that it can help to figure out what the product needs to do. It may not in the cleanest rendering, but it’s better to figure out problems early on than to miss them by spending too much time building a prototype that doesn’t fulfill the business model.

Ultimately, deciding to take on technical debt should be the result of knowing how clean the code can be, and whether it is worth building code that is that clean. Understanding the benefit of early feedback, the cost of debt and errors, and the likelihood of errors still makes coming to a decision on technical debt risky, but based on the realities of development. There are some areas that should not be subject to technical debt (those that are integral to operating abilities and user experience) but there are also those that benefit from being released quick and dirty.

To read the full post go here.

http://www.ontechnicaldebt.com/uncategorized/when-technical-debt-is-better-than-clean-code/feed/ 0
Is DevOps Good or Bad for Technical Debt Reduction? http://www.ontechnicaldebt.com/uncategorized/is-devops-good-or-bad-for-technical-debt-reduction/ http://www.ontechnicaldebt.com/uncategorized/is-devops-good-or-bad-for-technical-debt-reduction/#comments Thu, 18 Jun 2015 19:30:42 +0000 http://www.ontechnicaldebt.com/?p=3510 read more]]> Continuous delivery and deployment pipelines force the clean-up of inconsistencies and holes in deployment through consistent automation. It also allows for work to happen between development, test, and production phases, which makes code easier to manage and reduces the risk of a security or operations issues. The DevOps approach can also enable the easy payment of technical debt.

DevOps allows for teams to consistently refactor in a quicker and more secure manner. The feedback cycle guarantees that the most pressing issues for the business are addressed promptly – and fixing bugs, security vulnerabilities, or usability issues can be  taken care of before the upcoming release cycle.

However, there are shortcomings to DevOps, as consistent iterative change can become erosive. As the same code gets worked on again and again, with classes and methods inflating, the structure and design of an application begins to collapse. DevOps magnifies this issue as small changes, experiments, feature and user interface work is happening in a constant cycle. The most dangerous example of this type of work is that teams often work on the code mainframe while code is still being developed – and they use conditional logic and flags to skip over parts, which are still under construction and buggy, at run time. This can become a problem if the feature is accidentally switched on before its ready to run, and it makes code more difficult to understand.  This is why the DevOps approach requires strict regulation; the constant deployment, day to day refactoring, documentation of features, and the removal of dead code presents many opportunities for mistakes.

The presence of a large number of tasks being handled at once by different teams is why DevOps lends itself well to a microservices architecture. Microservices allow for multiple teams to independently work, deploy, and refactor a certain project. It allows for each team to decide what tool or language best suits their needs. However, as more services are added, the costs of testing increase across varying languages and frameworks which also makes tracking vulnerabilities difficult. The added complexity of each service also makes switching from team to team less feasible.

The other downside of the DevOps approach is that it promotes shortsightedness in development. With constant feedback flowing in, working on fixing bugs and immediate fixes leaves bigger picture strategic problems unaddressed. Architecture and design debt grows because immediate technical debt is seen as the priority. As this strategic debt grows, developers have to work with an aging platform that slows down the ability to respond to and make changes.

When it comes to DevOps as an approach that is better suited for technical debt reduction, it is both good and bad. In order for it to be a truly successful method of development an extreme amount of discipline and foresight is needed. This is the usual conclusion reached when speaking about technical debt – detailed management of debt is a necessity in order for a system to function as needed.

To read the full post go here.

http://www.ontechnicaldebt.com/uncategorized/is-devops-good-or-bad-for-technical-debt-reduction/feed/ 0
The Causes Of Technical Debt Do Not Exist In A Vacuum http://www.ontechnicaldebt.com/uncategorized/the-causes-of-technical-debt-do-not-exist-in-a-vacuum/ http://www.ontechnicaldebt.com/uncategorized/the-causes-of-technical-debt-do-not-exist-in-a-vacuum/#comments Wed, 17 Jun 2015 19:22:15 +0000 http://www.ontechnicaldebt.com/?p=3504 read more]]> Time to market pressures are often identified as one of the key causes of technical debt. This results in a tension between releasing a poor quality application early and releasing a high quality one late. The advantages of releasing a product sooner rather than later can be immense and extremely beneficial for a business – and in the rapidly changing tech environment falling behind can be disastrous. However, one of the common misconceptions about technical debt is that it is only relevant at the code-level of software development, when technical debt can be incurred at any point of the software development life-cycle.

There are two categories of technical debt: intentional and unintentional. For either of these two types of technical debt there are usually positive short term consequences (due to early delivery) and negative long term consequences (due to a low quality standard of software). Despite this similarity between unintentional and intentional technical debt the distinction of their causes needs to be made in order to reduce the prevalence of this quality killing phenomena.

Intentional Causes of Technical Debt:

  • Time constraints placed on development
  • Source code complexity
  • Business decisions which lack technical knowledge and make communication difficult

Unintentional Causes of Technical Debt:

  • Lack of coding standards and guides
  • Junior coders with little experience and poor skills
  • Lack of planning for future developments

The long term effects of the above are longer work hours, error and bug prone code, customer dissatisfaction, and increasing source code complexity. There are several processes that can be set into motion in order to keep technical debt at bay, or to address it before the negative consequences of it reach untenable levels.

They include:

  • Refactoring
  • Bug fixing days
  • Code Reviews
  • Clear coding standards and guides
  • Communication between business, management, and developers

While up until this point, the post does a good job of delineating the common causes, effects, and resolutions of technical debt – it is missing a key factor that would lead to the successful management of technical debt in any organization. Many of the causes of technical debt outlined above are a result cultural issues.

Unrealistic time constraints, green developers, little or no coding standards, and poor communication with the management are results of a method of operation for a business. For example, developers with little experience need to trained in order to reach the standard of work that is expected and needed for the business to thrive. Notice that in this instance there are two things needed: a clear set of standards and sufficient time allotted for training. These two items by themselves are causes of technical debt. Therefore, there is a clear connection between one cause of technical debt to another, and often times one is not present on its own. If there are unrealistic deadlines in an organization there are probably also untrained workers, non-existent standards, and a lack of communication with management to solve these other problems.

No cause of technical debt exists in a vacuum – and in order to address it there needs to be a conversation on why it is occurring and an understanding of what needs to be done to deal with it. If time constraints are a serious issue in an organization because management wants quick releases – the cost of these unrealistic time frames needs to be explained. If this exchange does not occur the cycle of poor quality code and technical debt build-up will continue.

To read the full post go here.

http://www.ontechnicaldebt.com/uncategorized/the-causes-of-technical-debt-do-not-exist-in-a-vacuum/feed/ 0
The Conflict Between Regulatory Compliance and Velocity http://www.ontechnicaldebt.com/uncategorized/the-conflict-between-regulatory-compliance-and-velocity/ http://www.ontechnicaldebt.com/uncategorized/the-conflict-between-regulatory-compliance-and-velocity/#comments Mon, 15 Jun 2015 13:52:37 +0000 http://www.ontechnicaldebt.com/?p=3496 read more]]> Regulation is a fact for every financial institution, which can be a challenge when competitive pressures are mounting –  but this is no more challenging than it is for the software that has been developed to use internally in different organizations. Technology is now the main source through which consumers and companies interact. While technology has become a game changer for many organizations, regulatory compliance has increased alongside this change. Technology, however, in the fast paced digital marketplace it operates in today, often outpaces the regulation set up for it. This requires that regulatory frameworks be able to adapt and evolve to changing technology.

It is often mentioned that the most regulated industries are those that are most vulnerable to disruption by newcomers. This is especially true for financial services where challenger banks and payment services providers have a lower compliance barrier to entry than established institutions. For them the bar is lower because of technical debt. Challengers to new institutions do not have the same burden of decades of accrued technical debt. The already established institutions have to retroactively fit in compliance measures to their technical debt burdened systems – and one of the greatest downsides of technical debt is that instilling changes into a technical debt ridden area is a very slow process.

Regulations are not always those imposed by external authorities but can also be those that have been implemented internally. Regulations do not stay static over time and many often continue to be defined as time goes on. This, therefore, requires that the process of implementing these compliance measures needs to be susceptible to change. It is then the case that when a piece of software is ready to be shipped, and fits into the regulatory framework of that moment, it may not remain within the regulatory rules further down the line. It also becomes increasingly difficult to be aware when compliance changes affect current systems, because changes to software are rarely thoroughly documented.

As compliance frameworks are increasingly granular it becomes more difficult to maintain the velocity that is needed to keep up with digital innovations. The conflict between compliance and innovation becomes a juggling act between proving that rules have been followed and reducing the lag-time as a result of the increasing levels of regulation.

As the amount of regulation increases, it becomes unfeasible to verify manually that rules are being followed. This means that compliance needs to be integrated into the very code, similar to other features and qualities. By automating compliance into software production it can be tested throughout development and can be changed due to infrastructure, application, or compliance modifications.

The larger an organization the more difficult it is to instill new automation – however, it is necessary in order to remain successful. Automation can be achieved by starting off with a small amount of work that can later be scaled for more teams and used as an example for future automation work. Ultimately, in order to be compliant, having an infrastructure that is amenable to rapid change in regulation and technology is crucial.

Read the full post here.

http://www.ontechnicaldebt.com/uncategorized/the-conflict-between-regulatory-compliance-and-velocity/feed/ 0
The Pressure of Digital Transformation and Subsequent Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-pressure-of-digital-transformation-and-subsequent-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-pressure-of-digital-transformation-and-subsequent-technical-debt/#comments Wed, 10 Jun 2015 19:36:42 +0000 http://www.ontechnicaldebt.com/?p=3492 read more]]> When planning 2015’s budget most companies left out new resources needed for a key generational shift: the change from a centralized technology support department into a sleek and fast digital line for business. There has been a great deal of attention given to the role of Chief Digital Officer as they are meant to lead these new digital aspects of the business in many organizations. Despite the excitement surrounding digital transformation, the majority of enterprise data, expertise in current systems, infrastructure, and operations is under the supervision of the CIO, and the CIO’s responsibilities usually encompass business/IT alignment, security, and managing the legacy portfolio. They do not include pushing through digital developments for the business.

IT departments are slowly beginning to rethink business in a digital environment. The big five IT changes that occurred 3 years ago (mobile, social, cloud, consumerization, and big data) created an unheard of amount of changes that need to be adopted at the same time. In most organizations the process of adoption is still in process, which may begin to signal that the ability to align what is achievable and what is needed might become unsustainable. The transformation businesses need to undergo in order to keep up to date with current technology, combined with a static budget and day-to-day processes, amounts to a mountain of technical debt that can be nearly impossible to get over.

Further discouraging organizations to take on large scale enterprise transformations is that the success rate of such tasks still hovers around only 30%. However, top performing companies are aiming to take on the challenge as the long term rewards in new digital technology are great. This demonstrates the difficulty that IT leaders face – digital transformation is likely to under-perform but since competitors are investing heavily in technology, the risk may like an attractive option.

When asking about the top priority for most CIOs in the upcoming year the overwhelming response is to improve applications to fit business processes better. This is not in line with a modern business’ needs for sustainability as technology has become a driving force in defining the markets leaders. Looking at the IT leaders misaligned priorities and the increasing pressure to undergo technology transitions with a stagnant and inadequate budget, there is not mass push for digital transformation by most organizations. There is not proactive engagement, from most companies, with the digital movement, as they are not willing to undergo the challenge of digital innovation.

Those that have been successful in the transition to digital are often either a top performer that invests heavily in technologies that are likely to boost growth or is an organization using financial acumen to strategically buy only the technologies needed. It is likely that those who invest too little in technology will not succeed – so there is a closing window for organizations to undergo the technology transition that is needed to allow their organizations to move forward.

Based on the above, there needs to be a change in the mindset of IT leaders on the risk of ignoring innovation for too long – along with the risks of taking on such innovation with insufficient resources – and its effects on the success of their organizations. The fear of mounting technical debt and a thin budget should be taken head on by arguing for more resources and explaining the necessity of up-to-date technology to key stakeholders.

To read the full post on digital transformation and the ticking clock for IT leaders to jump on board click here.

http://www.ontechnicaldebt.com/uncategorized/the-pressure-of-digital-transformation-and-subsequent-technical-debt/feed/ 0