Photo by Suzanne D. Williams on Unsplash
I’m going to first share why digital transformation of an enterprise should be easy. Then I’m going to share why this seemingly pipe dream is such an effort. I’ll simplify this effort and share the view of one such partial effort. My frustration as a digital practitioner is my crystal clear understanding of how to do this and my inability to drive or lead this effort through best-practices. When I speak of best-practices we should all reminisce of past, successful digital transformations. This is real. Many companies have achieved enlightenment and now enjoy the fruits of their efforts, fully transformed.
Let’s first understand digital transformation, what it is, why we all want it.
Digital transformation is a process that involves the use of technology to improve business processes, increase efficiency, and improve customer experience. It can be applied to any organization, regardless of industry or size, and can have a significant impact on the way an enterprise operates.
The goal of digital transformation is to create a more efficient and effective company by using technology to transform traditional business practices and processes. This can include implementing new technologies such as artificial intelligence (AI), machine learning, and the internet of things (IoT) to improve operations, increase productivity, and enhance customer experiences.
Digital transformation can also involve changing the way employees work, including introducing new technologies such as virtual reality (VR) and augmented reality (AR) to improve collaboration and communication. It can also involve changing the way customers interact with the company, including using AI to personalize their experience and provide them with relevant information.
Overall, digital transformation is about improving the way an organization operates and providing better services to its customers. It can help organizations become more competitive, increase profitability, and improve employee satisfaction.
At it’s core, digital transformation is the verb that describes the translation of a business, performed by it’s customers, employees, contractors, and partners into a digital abstraction of the same. This abstraction naturally is represented by data, it’s shape and it’s movement. Simple right?
As a solutions architect and integration specialist, I’m generally secured to provide the solutions that may make up all or a portion of this digital transformation. My technical counsel and negotiating powers are limited by the level of respect I can acquire and my involvement in current implementations where I may assume responsibility. It’s very clear that we all want to do what’s best hence the consulting firm’s mission to employ best-practices however, the reality of almost all situations is compromise. This compromise comes at a price.
As an architect we have marching orders to create solutions that exhibit quality, are protected (security), and always consider reuse and/or refactoring. And, as a deterrent, come the constraints of time, money, people, politics, power, and influence. I hope you can feel my pain. I desire purity and the application of best-practices. This is not reality.
I am now going to describe what I consider an acceptable solution to one of my past engagements. The component systems have been changed to protect my prior client’s identity. This solution is not perfect however, I want to help you visualize a right solution. I will then describe events that changed the acceptable solution to an unacceptable one by my standards. The requirements for this were easily understood and my initial solution satisfied those requirements by the book. Be aware that changes in solution really equate to subtle changes in many times, undocumented requirements. I’ll save that discussion for another post.
The client business, has been sold an off-the-shelf (OTS) system that manages payroll. Currently the company manages the transfer of timekeeping to the payroll system manually. The back-office has the ability to obtain employee timekeeping from a legacy COBOL-like system that runs on VMS (1970s tech). The need now is to have the COBOL-like system call a MuleSoft platform and ultimately create a new paycheck in the OTS system.
I’ll describe the required solution not as mine but attach it’s ownership to what I’ll term the design team. I was hired to accept responsibility for the integration of this overall design. At first glance, we have an obvious solution consisting of three components. An experience component used by the timekeeping system to initiate the new paycheck. It will be a TCP socketed integration but not complex. The process component will transform and manage differences between the legacy timekeeping system and the payroll OTS system of reference. Easy right? The system component integrates the OTS system and protects this payroll system of reference. I have described these components as best-practice Mule design. At a high level, it all seems very clear. And, if I were the Mule developer, I would tackle this project with enjoyment and gusto. I will now describe some subtle constraints, undocumented requirements, and an unreasonable timeline.
As I became involved, I was introduced to the high-level architecture of this project and shared deadline of August for this first phase (paycheck creation) in a single global market. The MuleSoft team is provided by another contractor (independent) and their supporting Mule developers working for the payroll OTS system my client had purchased. Sounds fine so far. Based on the three components I described it all seems feasible at this point. While the paycheck creation is temporal or not fully autonomous, the OTC system will just update the legacy timekeeping system using existing Mule APIs. Easy.
After I created the gannt chart within the project plan for the August deadline, I mapped out the TDD completion, the RAML creation, the actual development, and the MUnit testing. Some of this would be in parallel but our agile approach will suffice to allow our success. We now had a plan.
The design begins with the visualization of data shape, and data movement. We’ll focus on a single POST of the employee paycheck. The legacy timekeeping system has no digital understanding of a paycheck. I quickly find that the Mule team contractor has already entered into discussions with the legacy timekeeping system folks. And, the Mule team contractor is hesitant to accept the fact that I will approve their designs before any Mule work is done. The problems begin.
The Mule team contractor already has a design from legacy system to their OTC system. This design does not consider my undocumented requirement to use predefined industry-standard APIs from which my client is a member of this industry-standard community. These APIs form a common language across my client’s industry. The Mule team contractor never considered these API footprints. And, they cannot easily transform their (OTC) needs into the PayCheck object hierarchy and related external object schemas. The current project plan is beginning to need serious revision. As a member of that “design team” I described, my responsibility is to do this design right and in accordance with my client’s requirements. The industry-standard API evolution is a company initiative probably to reduce the need for periodically hiring outside integration experts. Reuse is still the word of the day.
I began discussions with Mule integration contractor and convinced him that this needs to be done right. The main concern here is the work done prior to my arrival and the ESB/Integration team’s project start upon completion of the high level design (HLD) by another contractor’s enterprise architect. The project plan I helped to create was too late.
There are many other problems that are causing failure to expectations my client’s top stakeholder. I’ll only say again that best-practice business, architecture, design, development, testing, and hosting tasks require purity and adherence. They are best-practices because they are patterns just like software patterns or recipes for success because they are proven (historical). This story above has already seen some relief in the initial deadline because the stakeholder has found an alternate solution for his current needs.
In conclusion, I’ll say again that I know how to do things right but enterprises are trying to achieve utopic full digital transformation of their businesses through the use of multiple partners, contractors, and IT experts. Also, they experience various levels of business and technical power exhibition within these teams. Digital transformation will continue its spread over the globe. It’s what’s for dinner but we might be eating late.