How To Reduce Technical Debt By Tapping The Enterprise Architecture
 /  Article / How To Reduce Technical Debt By Tapping The Enterprise Architecture
How To Reduce Technical Debt By Tapping The Enterprise Architecture

How To Reduce Technical Debt By Tapping The Enterprise Architecture

Find out how to reduce technical debt by mapping business and user requirements in an enterprise architecture. The results will cut the costs of finding and fixing software defects in production software.

Often, DevOps organizations neglect the critical connection between technical debt and enterprise architecture. Without the information that resides in EA, the future needs of software are almost impossible to determine. Without defining those requirements, reducing technical debt is impossible.

Technical debt is the result of suboptimal development that creeps into IT projects. You can’t reduce technical debt without looking at the whole business-to-DevOps process, which means starting with an enterprise architecture technology map and defining common technical processes to support converging business processes. Then comes framing software architecture to be agile where business flexibility is likely to be demanded and paying special attention to small changes.

For most companies, EA is a structured modeling process that defines business tasks in terms suitable for translation into IT projects. Business goals and requirements are the inputs to EA, and process definitions are the output, which is handed off to software architects for translation into development. This definition alone should demonstrate that EA has a critical role in continuous or Agile software development.

Use EA technology map to reduce technical debt

Development teams understand technical debt as the result of taking development shortcuts rather than designing for optimal utility. What they often miss is that optimal utility has to be assessed against business needs and not just against technical efficiency or the use of advanced technologies. The missing ingredients are:

  1. a technology map that defines the direction business goals and requirements changes (including governance) will take, and
  2. cross-business process evolution planning.

Both are best obtained from EA.

A technology map is a sensitivity analysis that looks at the way that basic business requirements influence business processes. It focuses less on what the processes are (which is a well-known EA goal) and more on what’s changing them. One enterprise reported an example of this in a cross-the-business requirement to make customer-facing personnel more aware of the specific state of a customer’s current relationship with the company. This trend was driving the business increasingly to web-based customer care and mobile device empowerment of sales and support personnel. It’s this relationship that the technology map should show.

The value of a technology map in reducing technical debt lies in its ability to show technical requirements trends across multiple business processes. That allows development teams to consider the total business implications of application evolution across all business processes and application tools. In the customer-facing example above, the map would show that application tools, in general, were likely to shift toward a web and mobile front-end model. That, in turn, should tell software development teams to aim for that technical goal for any customer-facing application, or even for applications overall. Such a decision could prevent taking a less GUI and device agile track in a project, which can significantly reduce the risk of adding technical debt.

Choices in reducing technical debt

Turning that “can” into a “will” demands defining common technical processes to support the general trends the technology map and cross-process planning identify. If there is a general requirement (such as our customer-facing example) across multiple business processes, it makes sense to consider implementing that requirement in a general way to apply to all the applications and business processes likely to be affected. In this case, cloud-hosted browser-accessible tools and a mobile backend-as-a-service strategy should be developed for the company, suited to the requirements of all the business processes already, or likely to be, affected.

The technology map and cross-process evolution planning drive a technology plan for support of common activities and trends with minimal risk of technical debt. To ensure that the effort to reduce technical debt isn’t compromised in software development, developers must consult with enterprise architects. The enterprise architect’s role includes knowing how trends at the business level will translate into points of agility focus in the development process. This isn’t going to happen without direct cooperation between enterprise and software architects who frame broad application design.

Experience shows that when any trend has an impact on multiple business areas or is promoted by multiple business goals and requirements, it is very likely to impact business processes and technology tools across the board. When an enterprise architect sees this situation, it’s important to communicate it to developers, and then work to define the likely requirements for business processes yet to see direct pressure for change. That will reduce the risk that tools developed for the current business requirements will end up suboptimal when requirements broaden.

The enterprise architecture lets you redefine Agile development, extending it beyond the notion of just being fast or responsive in an abstract technical way, to picking the right feature and technology pathways to follow. For example, experience shows that even a limited requirement to extend application access to mobile workers is a signal that mobile empowerment is going to be a priority within two to three years. That means it’s important to frame a full empowerment strategy at the first sign of need, and EA input is vital in making sure that strategy will prioritize the places most likely to need mobile support.

Reduce technical debt with EA, software integration

Most companies that undertake an EA and software integration like the one described here will succeed in controlling and reducing technical debt for large projects, particularly greenfield ones. The problems typically creep in later when small changes driven by specific requirements in one business area take an application or component away from the overall business trend line. To ensure that doesn’t happen, you’ll want to integrate EA practices into application lifecycle management (ALM) so that the trend line of changes is extended into the change management and testing cycle for applications.

Enterprise architects should always be collaborating with development teams to develop the test data needed for ALM and to formulate compliance and security strategies that will remain solid even if, over time, it’s necessary to provide application access and information support to more workers. In fact, EAs should sign off on changes in applications or deployment practices (including DevOps), representing the fusion of business operations and technology.

A few organizations are now proposing the seemingly revolutionary step of actually integrating enterprise architecture into the development process, making the enterprise architects key players in developing applications or managing application changes. Whether this step is taken or not, eliminating or reducing technical debt demands closer collaboration between architects and developers, and the extension of that collaboration through the entire application lifecycle.

Source: searchcloudapplications.techtarget.com by Tom Nolle

You might also be interested in …

Related Posts

Architects Are Key To CIO Success In Digital Strategy
Article
Architects Are Key To CIO Success In Digital Strategy

It seems the CIO is getting popular again in executive circles. I have predicted this for many years as digital society forces technologists out into the lime-light and as business, government, and society run more and more on technology over antiquated business patterns

Four key challenges to digital transformation projects
Article
Four key challenges to digital transformation projects

The World Economic Forum calculates that digitisation could deliver $100 trillion in value to global businesses across the next decade. However, not every business will succeed in gaining a share of this due to failing to overcome impediments.

Digital is turning CIOs into business executives
Article
Digital is turning CIOs into business executives

For 84 percent of CIOs at top-performing digital organizations, their role has substantially widened beyond IT, with innovation and transformation being their prime responsibilities, according to Gartner’s 2018 CIO Agenda report (registration required).

Banks aim to reach digital maturity by 2020
Article
Banks aim to reach digital maturity by 2020

MALAYSIAN banks are steadily embracing digitalisation and are expected to focus more on investment in technology for the next three years to ensure further growth. A study by Ernst & Young (EY) on Global Banking Outlook 2018 revealed that 66% of the research respondents target to reach digital maturity by 2020

4 ways data will drive health transformation in 2018
Article
4 ways data will drive health transformation in 2018

Medical records, prescriptions, wearables like the Fitbit and Apple Watch and even social media all contain potentially valuable health information. With the size of the digital universe continuing to grow exponentially, and the promise of next gen tech like AI and machine learning promising instant transformation.

Related Certification

ATD Solutions

Architecting Digital Transformation


Read More

Newsletter

Keep updated with our latest news, promotions, events and more.