zimmytws - Fotolia
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:
- a technology map that defines the direction business goals and requirements changes (including governance) will take, and
- 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.
Get expert advice on eliminating software defects before release
Why reducing defects and rework in Agile is developers' dream
What's good about technical debt?