Fully Automating IT Will Start an Era of Agile Business. Let Me Explain Why.

Imagine automating IT so it can instantly deliver applications that support how the business wants to operate. This is what Instant IT^® business design and AI-generated applications do.

The Problem: IT Cannot Scale, which Is an Obstacle to Business Agility

IT today is asked to implement digital, analytic, and AI technologies that enable the business to adapt quickly, but IT is labor-intensive, time-consuming, expensive, and cannot scale, which I addressed in an earlier post. It described the benefits of Instant IT automation: a 10,000% increase in IT productivity and a 60% reduction in application TCO. Because business cannot be agile without automating IT, this post explores how IT works and how Instant IT changes it and delivers these benefits.

The Structure of IT Work Today

IT is intended to meet the needs of the business, and its work is organized into several distinct activities:

• Requirements, which define what the resulting application is to do for the business.
• Design, where the application is planned so that the requirements are satisfied.
• Construction, building programs and databases that conform to the design and deliver functionality specified in the requirements.
• Testing, where programs and databases are integrated, test cases are processed to confirm they operate as designed, and bugs are identified and fixed when they don’t.
• Deployment, putting a completed and tested application into production for business use.
• Maintenance / Sustainment, keeping an application up-to-date and operating properly over its life.

While these activities are distinct, they have dependencies which need to be recognized. Each requires its own disciplines and skills, and produces artifacts used in subsequent activities, as shown in Figure 1:

Figure 1: Typical IT technical roles and interrelationships in IT solution development.

This breakdown of activities is necessary to support the design, development, and sustainment of the thousands of code and data objects IT manages. Unfortunately, artifacts produced for an application are difficult to keep current over time, except for those essential for the application: its programs’ source code and physical data designs. Keeping an application operating as the business needs is a challenge, and results in technical debt when IT can’t keep up with needs of the business.

Instant IT automation simplifies these activities, using business design as the method to elicit business requirements and automating design and development of a ready-to-use application. In its essence, IT work is boiled down to three core activities:

• Requirements elicitation, which must accurately capture how the business and the application that supports it need to operate (Requirements, in IT activities above).
• Application representation, which structures requirements into a form that is a specification for the application to be built (Design, in IT activities).
• Application development, translating the representation into a working application that satisfies its requirements (all remaining IT activities).

Examining IT’s problems carrying out these three activities and Instant IT’s reinvention of them shows how Instant IT changes and automates IT work.

Problems with IT Requirements Elicitation

Requirements elicitation focuses on capturing the operational needs of the business, called functional requirements (non-functional requirements refer to operational aspects of deployed software). There are three areas of functional requirements that must be addressed: actions that are to be performed; data used and interacted with; and rules to be applied to support operational actions and keep data correct.

Business Action Requirements Elicitation

Actions are tasks done when performing work.

IT requirements are often qualitative descriptions of software that are useful but leave many operational details unspecified. Licensing applications has been the preference over the past few decades because of the time, resources, and cost required to build them. When eliciting requirements, IT generally focuses on what software will be used for and doesn’t get down to the who, what, and how of operational actions it must support. These important details are discovered when modifications are needed to fit licensed software into business operations.

As shown in Figure 1, IT business analysts capture functional requirements that describe how businesspeople want to use the application. In most cases, Word, Excel, and PowerPoint are used to document actions to perform, review them with stakeholders, and communicate them to technical staff. Unfortunately, work products like these require significant effort to keep current and consistent as requirements accumulate and evolve.

Business Data Requirements Elicitation

Data is an individual data element interacted with when performing an action.

Operational business requirements focus on providing operational functionality as the primary concern. Data is generally an afterthought, particularly if licensing an application is the choice. Applications come with their own data element definitions and database designs. So, data is as it exists in the application and an analysis of its physical schema and data content may be made. When an application is licensed, an analysis is performed of data existing in IT that will be used to populate the application database when it is implemented.

While action requirements are descriptions of business activities that need to be supported, data requirements largely focus on an application’s physical data content and structure and not on its broader, enterprise use. Enterprise data management may be included, but typically this is related to an enterprise data model, discussed below as an IT representation of data.

Business Rules Requirements Elicitation

Rules are applied, as part of an action, when a decision on how to proceed is made.

A rule establishes criteria to apply when making a specific decision, like whether to proceed or stop a transaction. IT requirements capture project success factors stakeholders emphasize, but do not specify rules explicitly. IMO, this is because documenting actions as functional requirements are too general to include specific decisions and rules to be applied to them.

While many organizations synthesize data usage into an enterprise data model, no such activity organizes or standardizes business rules. Consequently, rules are often left until program design and/or construction when attention is on embedding rules that support a specific business action correctly. This makes rules specific to the program that contains it instead of making rules universally applied in every business action.

Summary of Problems with IT Requirements Elicitation

Of all the issues associated with IT project development and management, problems with business requirements definition ranks at the top of the list. As Forrester reports, “When it comes to getting requirements right, companies struggle on two primary fronts: requirements definition and requirements management … The real opportunity for improvement lies in requirements definition and in how different development methodologies treat changing requirements.”

Eliciting complete and specific business requirements has been the most challenging aspect of delivering effective applications. Forrester says, “Poor requirements practices alone can doom any application development initiative.  No matter how well architected, well-constructed, or well-tested an application might be, it is essentially useless if it fails to meet business needs.” Problems eliciting accurate and complete requirements are behind the Standish Group findings in 2020 that 19% of projects fail and 50% are challenged to meet business, schedule, and/or budget objectives.

The underlying obstacle is that IT requirements are typically captured in a document that is part functional requirements and part business case. Requirements in this form are a problem because language is imprecise, and therefore not suited to long-term utility. There are tools that capture requirements in a structured manner that use object and/or data models, which will be discussed in Problems with IT Application Representation.

Problems with IT Application Representation

Business requirements need to be represented in a form that defines a software application that can be used for developing and implementing an IT solution. Representations, as shown in Figure 1, are developed by application architects, software engineers, and database architects.

IT Representation of Business Actions

Working from functional requirements, application architects create a functional model that represents business functions in groupings, which software engineers use to organize a view of what it is to happen dynamically in the system with application objects and data. The resulting diagrams show pieces, like application architecture diagrams, interaction / sequence diagrams, object state diagrams, and technical architecture diagrams, that provide useful views of a system to be developed and implemented.

IT Representation of Business Data

Database architects design the physical data objects and structures, based on the application architect’s diagrams, the application will use. This is the foundation for supporting work actions throughout their operational cycles. The content and structure of data is solely focused on the application’s design and needs.

Enterprise data management may provide data governance and ensure adherence to enterprise data standards. Enterprise data management typically uses an enterprise data model that organizes enterprise data as a normalized, third-normal form structure. Built by enterprise data architects who have different objectives, enterprise data models rarely align with physical data structures.

IT Representation of Business Rules

Software engineers use the representation diagrams above to design programs that will make up the application. A program design sets objectives, technical specification, and boundaries for the program to be constructed. Rules are specified or implied by representation diagrams and the data design.

The software engineer finalizes the architecture of the system and produces specifications for programs that are to be developed.

Summary of Problems with IT Application Representation

IT representations are used to transition from a set of requirements captured at a point in time to programs and databases that support them. IT representations, in practice, operate as a technical version of the Telephone Game where each representation transitions to another that adheres to its own discipline, objectives, tools, and artifacts: requirements à architecture diagrams à database designs à program specifications. IT representations are transitory, and it is a challenge to keep them consistent, current, correct, and concise.

IT representations, in fact, will be unnecessary when application development is automated: requirements à a ready-to-use application.

Problems with IT Application Development

Whether using models or other IT representations, rendering them into a working application makes them into the programs and databases that are IT business assets. IT representations are transitory, but operational code is vital and long-lived. However, building programs and applications have their own challenges.

Actions, data, and rules need to remain stable while programs and databases are constructed, which can be a problem when the time required is months or years because business needs can change. Similarly, changing programs and databases to support new business needs also takes time. The time required for rendering business needs into application programs is a problem that needs to be eliminated.

Problems with Developing Programs

Regardless of the models, programming languages, or tools being used, developing a program requires interpreting requirements and representations into working code. Translating them into procedural steps for a combination of actions, data, and rules and assembling them into a working application takes time.

Common problems with programming include misuse of the programming language (syntax), incorrect program logic (inaccurately programmed rules), and runtime operation errors (such as data and integration). Debugging is finding and correcting these errors. Testing is a process that attempts to identify errors and exceptions before a program goes into production and is used in the business.

There is a wide range of tools to facilitate the program development process: code inspection; integrated development environments; testing automation; and DevOps. These tools can be beneficial, but the root cause they address is the human element involved in programming and application development. 

Problems with Developing Databases

Database schemas represent physical storage of data, which is used by a program to access and use data. This makes data design necessary for developing a program, so therefore, data design needs to be completed before a program can be developed. In practice, this means databases are designed before all program usage – access paths, intermediate data, and so forth – of data is known.

This is not just a problem for application development. The linkage of programs to physical data storage and the program refactoring needed when data structures change are why individual applications have their own databases – it is too expensive to have a database shared between them.

Summary of Problems with IT Application Development

Implementing and maintaining application programs and databases is the purpose of enterprise IT. Programming activities remain labor-intensive, time-consuming, and expensive because they are complex to build, maintain, and manage:

• A program is a set of logic that combines actions, data, and rules. Constructing a program requires a correct understanding of how they come together.
• Building a program requires actions, data, and rules remain static for the duration. A program cannot be completed if what it is to do keeps changing.
• Changing actions, data, or rules can ripple through programs and/or databases. A new business need can impact many IT code and data objects, requiring significant time and effort to identify and enhance.

Business today needs IT to be automated, which is what Instant IT does.

Wait – what About Model-Driven or No-Code/Low-Code Development?

There are tools that systematize requirements gathering with IT representations. Referred to as model-driven or no-code/low-code development, they use models, components, and diagrams as interrelated design specifications for application development. All diagrams and elements need to have aligned usage, notations, and semantics.

The problem with model-driven development is it relies on keeping its models and diagrams consistent, current, correct, and concise. Keeping them so can be burdensome and overwhelm a project. Experience with CASE tools in the 1990s show that keeping models current keeps them from being effective over time. And while CASE principles evolved into standards like UML, model-driven development challenges remain.

Instant IT Transforms IT Application Development and Management

The challenge for automating IT is one of accelerating application and program development, making them adapt to new business needs quickly and easily, and reducing the labor, time, and cost required. Instant IT does this by reinventing application development.

Reinventing application development begins with changing the definition of an application from a set of programs and databases to a collection of user interactions with shared data and rules. Instead of programs and databases, this focuses on the user experience and consistently applied data and rules. Instant IT combines business process modeling / reengineering and AI no-code, non-model driven, application design and development.

Instant IT Business Design Replaces IT Requirements

It begins with business requirements, defined as an operational workflow that captures discrete elements of a business operation and their relationships as business metadata, in an Instant IT business design. A business design captures how the business needs to operate, no matter how unique.

A business design includes diagrams of operational workflows, roles, and process actions, which are expanded into a process action workflow diagram, such as for a sequence of web pages:

In other words, an Instant IT business design focuses on how the business operates instead of on a general description of software functionality. The business design is includes defining data and associated business rules interacted with when performing a process action, and API process actions:

Thus, elements of a business design as a replacement for IT requirements are the simplicity and precision of its content:

• Process workflows for the exact way the business wants to operate.
• Process actions performed in business processes.
• Process action organizational roles and responsibilities.
• Process action data interactions and method of interaction.
• Data element definitions used with semantic consistency in all processes.
• Business rule specifications.
• And too much more to detail here.

The beauty of business design is that it changes requirements elicitation from descriptions of functional requirements to laying out business processes and actions, how the business wants to operate and perform its work, and the data and rules used.

Instant IT transforms application development into deciding how the business wants to work instead of figuring out work IT will need to do to deliver an application.

Instant IT Eliminates IT Representations and Rendering

Instant IT computer-generates complete, ready-to-use applications from business designs instantly. It does this by:

• Validating the business design – ensure that the business design is complete, consistent, and usable as an application specification.
• Analyzing data affinities and access paths – determine data objects and their content, including history and object linkages. Best practices are incorporated so there are no data redundancies or duplications, abstractions requiring programming to select data, or inefficient data access paths.
• Having the client manage the business design – control business design authorizations, approve application features, and publish API contracts and documentation.
• Having the client control the technology selections – set the databases, API endpoints, application container destination, and so forth, to be used for the application.
• Generating the application – computer-generate the database schema, units of code for individual rules, formats, APIs, and other application features. A code scanner is used and a scorecard for the generated application is included in the generation process.
• Delivering the application in a container – prepare a Docker container and deliver it to the destination as specified by the client.
• Providing general management features – monitor and control the Instant IT metadata and applications with instant IT’s management features.

For more information about InfoNovus Technologies and a fuller description of Instant IT and its capabilities, visit www.infonovus.com.

Instant IT Enables Business Agility and Adaptability

Data and rules-based business design, and automated application development, transforms IT from being labor-intensive, time-consuming, and expensive, to being automated, instant, and economical. Instant IT uses AI to automate application delivery, increases IT productivity 100-fold, and lowers application TCO by 60%.

Executives want applications that are implemented quickly, support how business units work, have low cost, and deliver fast ROI. Automated application development transforms time and resource considerations, standardizes on core technologies, and reduces the cost of acquisition, time and effort needed to deploy applications without incurring technology debt. Operational business designs and computer-generated applications increase business partners’ satisfaction with IT and let executives focus on continued operational improvement and innovation.

When IT is transformed through automation, it can scale easily to enable a company’s agility and adaptability. Business agility will depend on the business’s operational readiness and change management capabilities, not IT’s speed of application delivery. Instant IT provides what a digital transformation is meant to produce: organizations able to respond to market changes, add digital capabilities, and create operational innovations quickly and easily.