System chaos...

System chaos...is there another state?

Here is my definition of chaos:

Demand focused on evolving technology running against legacy systems that are difficult to change.

Breaking the definition down:

Demand:

Technology is constantly evolving at a quicker pace. This is a constant that must be addressed. Technology evolution has moved faster than the Business Domain models that rely on this critical corporate technology. Creating a continual challenge: a collection of competing new technologies against static legacy systems.

Technology:

This term encompasses the complete scope of technology affecting business. This includes;

• proprietary software platforms
• virtual (cloud) environments
• closed data models
• distribution of computing - main frames to microwaves
• new devices coming on line every day.

Legacy:

Large complex data models (business critical) wrapped in a variety of technologies.

While the front end may be 'Cloud-able' the large data structures - the back end - depend on the age of the Business Model origin.

• what is the base technology
• how old is the base system
• what are the vendors upgrade plans
• how strong of a voice in 'features' does the business have

'Change' as a constant is known both as a costly and time consuming effort with questionable benefits. Weigh that against the constant evolution of technology and the impasse or evolution that has already been crossed over or is near term.

Note:

As a technology professional, your voice carries more weight. Be careful what you ask for. The latest Power Tool may have a learning curve that directly offsets the benefit. Wait! There is more. How does the latest power tool line up with 'my' business domain? A very good question.

Domains: the undiscovered business unit

Accounting? That model is well defined. Human Resources (HR)? Evolving, but defined by clear regulations. Accounting and HR are internal business units that represent a part of the defined business model. This is only a portion of the domain model. The 'product' is the core object as it represents the value the business adds.

To The Programmer: The portion of code you are refactoring has to comply with the business domain. Often the code will be at odds with the business model and needs to be refactored.

The domain model has to be both global and specific to the business model need.

How does a programmer get that information?

It doesn't matter if you are a component in an ETL factory, the Interface to the UI model or buried deep in Security Context, understanding what the business does is a critical build component.

The agile model is structured to bring stakeholders and doers together to build success. Often the task and backlog reviews lack stakeholder participation. The business stakeholders are critical to keep the "program" in line with the business.

Traditional approaches were not meeting the needs of business. A more code forward model was needed. Legacy systems are generally out of synchronization with a CICD (Continuous Integration, Continuous Delivery) model. This goes beyond the technology involved, it also has to encompass the business workflow model which likely follows a very serialized process.

The Right Technology to Fit The Need

What is the right technology or should be falls to the corporate decision maker that decides on the budget for the IT department. This is the position that decides the technology direction for the company. Here are some business models.

Finance:

The Financial model has a lot of regulation and outside factors that significantly impact the business model. A better model perhaps is a company in the manufacturing or wholesale space. It shares a regulation space that is similar to the medical system space.

Manufacturing:

AI and automation is constantly employed and improved to streamline the process from input to finished product. Advancement has been focused on the automation of the process and not the business model. Businesses in this space are behind the curve significantly and are playing catchup to become 'cloud' compliant.

Wholesale:

Again, the technology focus has been on improving product flow rather than automating the full business model. Another segment that is behind the curve and struggling to catch up.

Wow! That is some big enchilada!

It is a significant challenge with technology that is behind the curve trying to evolve to the cloud.

Like in the movie, "The Hunt for Red October", when Sean Connery said, "Some things in this room do not react well to bullets..."

While not quite a nuclear explosion; the choice of what technology to choose is critical. Get it wrong and you are behind the curve or on a curve that ends in a cul de sac. The Cul De Sac is a closed space with no outlet.

There are no gentle solutions to a technology termination point. Today, platforms rely on continual upgrades. This could be a problem or a blessing.

What is the best option? This is where the role of the 'development' team can shine or ...

The Stakeholders know what is important, the Engineers need to make it happen.

Planning:

Position 1: Current system is dependent on expiring technology with no upgrade path.

Solution: Green field development or replacement with off the shelf (possibly with operational edits) software. Often this position is on a single source platform.

Position 2: Current system has an interim upgrade that is still dependent on old technology.

This position often presents the most challenges. Generally multiple platforms are involved. Depending on the industry, the main system that drives the primary business objectives will likely be comprised of proprietary closed systems.

The 'additional' systems in this environment will be focused on the 'Business Decision Makers' and will include systems focused on aggregating and presenting information.

Position 3: Current system is modular, upgradeable and is CICD compliant

Unless this is a brand new business, this model is the goal and the preferred model. So, how can positions 1 and 2 be re-aligned?

Position: A 'position' represents a particular software range that exabits critical features that make the company function.

Companies facing P1 are examples of companies in a technology crisis. The change must happen. The solution is generally a wholesale conversion and that can be gnarly. The alternative usually results in a less satisfactory experience. The business closes.

Companies in the P2 position

Time is of the essence to meet the new demands of the cloud platform. The internal systems are proprietary and generally supported by an 'Outside' vendor. An outside vendor present issues that impact the ability to 'move forward' with an enterprise platform.

Options?

1. we are ready and they are not
2. they are forcing the change
3. nobody has a clue what to do next

The first two in this list are hopefully the event that drives the process. The list is ordered in decreasing preference.

#1

The golden space to be in is where the business is in line with moving forward and the driver behind the change. This is where a partnership can be established between the customer and the vendor to move the technology forward.

#2

If this is a technolgy forward position, this can be beneficial. The key item here to consider is that the business is out of sychronization with the enterprise platform.

There are far too many ways this path could go sideways. Here the decision should focus on the business domain and the cost of the partial upgrade(s) versus a complete replacement.

#3

Sadly, many decisions are made in this space. Lack of information, platform enfatuation, or no choices left.

As a professional, lack of information should be the exception not the rule. Generally, this condition arises out of relying on 'specialist' who are slow to deliver. Replace the specialist if this is the issue or crack a book.

Platform infatuation is a situation that probably requiers a 12 step program to resolve. In the not so distant past, COBOL ruled the business world. Now there are a kaleidoscope of products and technologies.

Platforms change and new platforms arise. Keep it as flexible as possible. Avoid blind dedication to a platform. That is the past where a physical month is equal to years in technology advancement.

The final condition, 'no choices left', could be the result of a proprietary platform that is deeply engrained or the system has reached the end of its supported life. Either way the path forward faces significant blockers. As this is a 101 level, that is beyond the scope here.

Summary:

Hopefully, I've presented a reasonable selection of items to consider. The 'base' that represents the technology the business relies on has to be evaluated against emerging technologies to answer the critcal questions and addressing key business metrics. Is the change required and to what exent? Is it a chaotic change or incremental? Is the business falling behind and what is the clear path forward.

Against this backstop is the maturing framework of the cloud and cross platform technology.

• Which CLI will the frontend team use?
• What is the definition of the public API or private API?
• What methods and data to expose and consume?

Largely, the platform and technologies come with the business domain. How the company faces change, falls to the chief technology decision maker. This stakeholder evaluates one simple question, over and over again: GO/NO GO.