Processes and Data

My wife and I have a side gig. We make chilli condiments. Our clients are mainly family, friends and a few third parties. We sell, directly most of the time, and also online, from our website.?? Neither of us had IT architecture in mind when we started this business, but what we implemented can be likened to enterprise architecture, on a micro sale. It involved a synthesis of two very important ingredients of every business, especially in the digital age: processes and data.

When we set out, neither the Internet nor social media marketing were on the periphery of our minds. We just wanted to make a product that satisfied our craving for a peculiar kind of chilli that was "cooked", and rich in flavour. However, to make the products, we needed information (data). What ingredients to use, where to find them, what names to call the brand and the products, what sizes to make them and in, what form, who were customers, etc. That was just some of the data that we had to acquire.

We also needed product specific information. It would never suffice to simply throw ingredients into a pot and hope that a masterpiece would pop out all by itself. We needed a recipe that identified the right ingredients, when and how to introduce them, in what quantities, proportions, form, rate, order, etc. It took us several months before we started to get some stable product definitions. That was a process. These days, we have about five products, and probably dozens of processes. Some active and some defunct. Not all are related to production runs. We have processes for procurement, marketing, accounting, etc.

Stepping back a bit, it is clear that the impetus for all of this activity was our desire for certain products. In this scenario, we are the business. With or without IT, we would still have pursued the objective. The reason we leveraged technology was because we anticipated some benefits. Therefore, our business, having started out with a vision for services that we wanted to provide to customers, decided to use technology to facilitate and expedite our aims. We had some data to work with, and processes to operate on the data. Processes for creating the products, as well as getting the products to real and potential customers. Of course, once we gained traction, other opportunities emerged, requiring more/new uses of technology. You get the idea of the twinning and cycle: business (vision and strategy) plus technology (data, process, ...). My focus in this release is limited to processes and data. However, I hope we all understand that modern IT is more than those two. Indeed, when most people think of IT, their first thoughts are of hardware, and the complex web of infrastructure, physical and virtual, that powers the Internet, the Cloud and AI. They forget that great value is released in data and processes.

The cycle that I just described, for our family business, is taken from a popular enterprise architecture (EA) framework, an excerpt of some of its early stages. Stripped of complex concepts, I think architecture frameworks can be intuitive to most people, when explained with analogies that are accessible to non-techies. They are logical, and it is what many people do, when they scale businesses from the kitchen/garage to the stock market, even though they never took an MBA. As the Solution Architect (SA), it is important that you always keep this in mind, i.e. the simplicity of the business-tech relationship. Of course there are nuances, and the core drivers (risk, complexity, scale) will add their own challenges, but the central theme is consistent.

I have never worked in an organization that actually adopted any of the EA frameworks (TOGAF, Zachman, DODAF, MODAF) completely. Rather, they pick and choose aspects that they have found beneficial. But there are similarities with our family business. Both start out with a business vision, and need to transition from a point of no-product and no-customers, to a place where they have a brand and market presence. All have to proceed through a number of step changes, to get to a target state. For every step of their transformation, the primary input was information (data), old and new; and the means to get to the next step was by evolving the existing processes. Bear in mind that the business is thinking solutions, services, revenue, value, brand, ROI, etc. Someone has to think tech.

As the SA, you are responsible for helping the organisation to remain in sync. When the business side changes, there needs to be a responsive and salutary change on the technology side. This ties back to a previous article. You help to maintain the alignment via continuous communicating with your key stakeholders. You effect bidirectional communication, about business and technology, as well as changes to the data and processes. In so doing, you help align the dynamics of the organization with the reality of your environment (internal and external). Using those processes and data as key transformational engines.

There is more. Beyond facilitating the business, what of the ways of working that pertain to your role as an SA, especially in the context of programmes and projects? You will observe that processes and data are at play once again. I talked about the primary stakeholder in a previous release, anchoring it on the concept of the service consumer in ITIL 4. In the discussions that followed, I explained that internally, a good tool for an SA to model the workstream is SIPOC, a Six-Sigma tool. I will not elaborate on the acronym here, as there is a wealth of information available online, starting with the link above. Suffice it to say that it has a strong focus on data and processes.

In a digital world, for businesses of all kinds, data (information) is the new gold. At the core of them all are activities/practices that operate on that information, i.e. the processes. Now this can relate to managing RFPs, the SDLC, procurement, a Sprint review, etc. In all of these, the organisation, or a unit within it, receives information, which it will process, and create some other information. In the software industry, one can begin to envisage how these can be linked in a value chain. There will be some corollaries in other industries. Starting with a demand or opportunity to serve a customer, a chain of data and processing blocks, evolve the input, until value is created.

SIPOC is closely related with two ITIL 4 guiding principles: 6). Keep It Simple and Practical, and 7). Optimize and Automate. It is good that one is aware of the importance of data and processes, but it is even better that organisations invest continuously to improve the quality of both. This is where major differentiation takes place, between industry leaders and other participants. As an SA, you can help your organisation get rid of redundancies and inconsistencies in the inputs to your processes. You should also collaborate with key stakeholders to trim processes down to within the perception granularity, and delegating to automations wherever possible. For services that are managed in-house, the gains in accuracy, efficiency, throughput and agility, all add up. Over time, those differences will help to put your organisation ahead of the competition. But there is value, even for non-core services, some of which may be factored out to third parties.

I have worked with some organisations to deliver or manage outsourced services. To be successful, we clearly stated the input and output quality gates, and we trimmed and optimised the processes. Then we documented and practised it, to prove their efficacy. Only then were we able to delegate the services to an offshore partner. But there is more! Hybrid working has become the norm these days, although some organisations are still uncomfortable with remote working. This should not be the case; your central role as SA can make a big difference that influences the rest of the enterprise. As the SA, you don't get to choose your teams or their location, but that is not a problem. What you do is to ensure that there is clear and specific communication on the inputs (data) needed, the required transformation (process), and the expected outputs (data).

In their suspicion of remote working, there is a truth that some organisations miss. The fact that you can't really supervise IT staff, unless you are standing on their shoulders, all day! But that means your new role becomes site-security, rather than architect, PM, BA, director or manager. The better way is to hire folks with integrity, build their competence, communicate your expectations, and trust them to do the work. You may be surprised that they will sometimes surpass the mark, and that, by a large margin!

This has been a rather long piece, but it is about two key concepts that run right through the whole enterprise: data and process. I have chosen just three perspectives here, to ginger your imagination. It will be great to hear from you all, and to see if/how this all resonates with you.

?

That is all for now. As always, do share your feedback/comments, or DM me, and I will respond, at the earliest convenience.?

Until the next release, adios.

????????

Intro | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Conclusion