Once in a while it is worth looking back beyond the last 10 or 20 years of technology, there are some [depressing] themes that lead to the conclusion that IT has never been able to make good on its charter. Rebadged solutions with improved technology disguise the inconvenient truth that IT avoids its biggest problems. This is the first of a 2-parter, the with items 3 to 5 in part 2.
It is worth remembering that ‘Systems and Procedures’ departments - the forerunners of IT - precede computers by some decades. Their role was to design, simplify and measure business processes. Clerks (actors) recorded [vast amounts of] transactions in ledgers (databases), or journals (logs) and stored on shelves and cabinets (filesystems) under lock and key (security) – collectively systems. Procedures were meticulously recorded as repeatable playscripts (scripts) for the setup, recovery and operation of business processes.
5 things currently often forgotten are;
Can you describe how the thing that you are working on right now benefits your business?
The reason that business bought into the use of computers , back in the 60’s, was to automate business processes. Commonly called the [Electronic] Data management function (EDM) its aim was to consolidate [redundant] data. Throughout the 70’s the goals were to support quality objectives during the burgeoning era of Total Quality Management (TQM) in response to the and the Toyota Production System, and subsequently the increases in speed to market with the 80’s consumer boom and globalisation in the 90’s.
Unfortunately, the EDM function, later known as the Management Information Systems (MIS) function of the 70’s and 80’s became fixated on exploring the bells and whistles of technology, forgetting its purpose. Large technology projects were not tied to any business strategy or product. Led on by a fledgling software vendor community intent on selling business process in a box, with monolithic platforms.
In the 90’s there was [some] realisation that IT needed to realign technology with business process as Business Process Re-engineering Programmes were initiated, but Y2K got in the way of these efforts. By the 2000’s service-oriented architecture (SOA) and ITIL purported to address this, but most IT organisations applied it to what they could control - their own department. The hard part – understanding the business – was seldom done in any meaningful way.
By the 2010’s the agile revolution had taken effect in the enterprise and the concept of a Product Owner is now well known – even when the product is a service. The product-centric approaches puts emphasis on customer engagement during development. There will be a future post on the negatives of scaling agile in the coming weeks.
Everyone needs constant reminders to review of the context of their work. Teams and products must have a justifiable purpose, and not just be job protection. Employers also need to recognise the need to dynamically re-skill as part of their strategy
‘Systems and Procedures’ departments, as were, clearly understood that the system was the combination of how people used processes and data.
The view of these 'systems' has been obfuscated through the changing name of the department responsible for it; moving from [Electronic] Data Management, through [Management] Information Systems, Information Services to Information Technology. These name changes distanced itself from the system of which it was a part. It had an effect on the people that have worked within the function - they became programmers, developers, software engineers. Even when IT uses the term ‘system’ - systems programmer or a system administrator – it refers to a technology component or software program, not the business system. Whilst ‘Systems and Procedures’ looked towards business operations, IT has mostly been looking in on itself.
Business Process Re-engineering remembered the system in the 90’s, and in the early 2010’s ‘Systems thinking’ was in vogue for the enterprise, but similarly to the way software vendors of the 80’s viewed their ERP offerings. IT proposed a single [point] solution without really understanding the problem.
Transformation necessarily includes people, processes and things, and some of those things might include technology, but is not limited to it. We mustn't forget how technological change impacts processes and people, and vice versa. For example, testing does not finish with developers functional tests and release to production, but in the form of feedback from real users, continuously.
The second part of this post continues with points 3 to 5
Read next about the unsolved problems that have persisted within IT for decades
Human experience and Purpose driven organisations
For a complete map of this series of blogs see here