There was a day, seemingly eons ago, though less than 40 years, when computer automation was just reaching its adolescence and major systems had to be carefully conceived and implemented with technology that was often as much impediment as resource.
In the middle of virtually every successful effort was the Systems Analyst; part planner, part organizational consultant, part subject matter expert, part technology translator -- and often part ward healer.
The Systems Analyst knew the players, the tasks at hand, the history of how those tasks had been handled elsewhere and the technological tools available for the current effort. It was the Systems Analyst’s job to ensure that everything in the effort made sense, was capable of realization within the effort’s constraints, and wouldn't end up with the involved groups beating each other senseless.
Systems Analysts were more likely to come from the operating management side, learning what technology they needed than from the technology side, attempting to understand the operations of a complex organization.
Without the Systems Analyst, most major automation efforts would have failed or fallen far short of their objectives. Today’s world for all its technological glitz, is no different.
(Not So) Fast Forward
Much has changed since those days, but not everything.
Managers must still make reasoned decisions based on sometimes incomplete information; staffs and target users must still learn how to perform their tasks, often starting from scratch; one’s competitors still have access to most of the same technology; and funding and ROI are still difficult aspects for most projects. Moreover, systems today must still be conceived, designed and implemented in an ever more complex soup of technological, organizational and human factors with failure lurking around every turn.
True, we've gained a great deal; most visibly, technology that has become increasingly capable, leaving ever fewer strictly technological hurdles and making most that remain likely to fall in the next several years. But we've lost some things as well.
One of the most important of those losses is the role, status and value of the Systems Analyst.
Today’s Systems Analyst: a Hollow Title?
So we face much the same challenges, albeit with more powerful tools, but without a major resource: the broad analytical role and trusted status of the Systems Analyst. True, you still see ads for the title of Systems Analyst, but most of them end by describing the specific software in which candidates must be expert, suggesting a failure to understand the true nature of the position.
Loss of the true Systems Analyst may be at least partially laid to two trends in business and automation.
1. So what is a Systems Analyst anyway?
There has been a subtle but far-reaching change in how we define a Systems Analyst.
From a single, comprehensive job description with real weight, the industry has segmented analytical functions into a number of linear job descriptions, including “Business Analyst,” “Computer Systems Analyst” (now a favored synonym for Systems Analyst), “Planning Analyst,” “Risk Analyst,” “‘Project Manager,” “Engagement Manager” and several more depending on your industry.
What remains of the role ascribed to the Systems Analyst after all of these carve-outs is neither comprehensive nor very effective in most projects, and there is no cogent protocol for getting these disjointed roles to work together in a single project.
Indeed, just describing the components as discrete parts of the overall challenge in a project often means either 1) that they are likely to perform as disconnected stovepipes, or 2) that the project can afford only some of them, leaving much of the effort’s challenges nominally un-addressed.
Either way, the continuity, flexible communications and feedback the Systems Analyst formerly provided can be lost even as the project congratulates itself on completion of this or that formal milestone.
2. Push button ‘A’ for approach ‘X’: Turning Concept into Token
Society has, for eons, taken successful concepts developed by visionaries and turned them into rote disciplines complete with arbitrary components and acronyms to match.
From Machiavelli’s attempt to instruct his contemporaries in how to be more successful at court, to Edwards Deming’s management and manufacturing improvements in the 1950 and 60's, rational thinkers have looked at how things worked and tried to develop ways to improve them. When applied in a thoughtful way, these and other conceptual frameworks have made major contributions to society.
Unfortunately, disciplines like these have in the past several decades, intersected with our tendency to ignore the underlying concepts, focusing instead on the details and making the entire discipline into a series of tokens or “check boxes,” quite capable of application with little or no thought.
The result, sadly but predictably, is often a project that conforms to the details: Six Sigma (with its Champions and color belted experts), or Agile (with its Scrums and Sprints), or Joint Application Development (with its interviews ad infinitum), or what have you, but fails to address or even identify the real problems or develop effective solutions to them.
Back to the Future?
So what must we do to recapture the broad value of the true Systems Analyst?
There is likely no quick fix to recapture the power and flexibility Systems Analysts once provided. It took decades, after all, for the definition and use of analysts in automation efforts to morph in to the disjointed techno-centric forms of today, and the penchant for detail that took us there is still alive and well in professional circles.
A good start would be for the automation industry to rediscover and re-embrace the fact that “system analyst” and “computer systems analyst” are not synonyms as is so often assumed today. While computer systems are an important part of virtually all automation projects, they don't fully represent the breadth and complexity of human, organizational and procedural systems facing most efforts.
If we can return to viewing systems in this more encompassing manner, we can not only broaden our definition of what it takes to function properly as a Systems Analyst, but also more clearly articulate the background and skills an analyst should bring to his or her task. We then can -- and managers must -- begin to demand and engage Systems Analysts with the skills required to truly address the full range of challenges facing today’s automation efforts.
Another valuable resource may be found in a highly developed conceptual framework known as Soft Systems Methodology or SSM. SSM was developed in the 1960s by researchers at the UK’s University of Lancaster, and though far from a household name, it deals quite effectively with the differences between tightly bounded technology systems and more amorphous human, organizational and societal systems, providing a conceptual framework for managing the continuum of highly structured to unstructured components often found in the same project.
SSM has much to teach us about efforts that often grow from an organization’s strategic business objectives and end up with deployment of specific computer systems that will hopefully support those objectives. It also describes, by inference, what we should seek and demand in a truly effective Systems Analyst.
Finally, as technology races toward a glowing future, becoming ever more modular and interchangeable, humans and their organizations are falling behind in their ability to leverage what technology can deliver. We need more, much more, focus by those responsible for the intersection between the human and technological components of society including, among other things, a more encompassing view of systems and how they are designed and evolved, by the user community in how they organize and staff projects, and in the educational community in what they define and produce as “systems” professionals.
Failure to do this risks a future with ever greater technological excellence in a muddled and at best marginally functional human and organizational wrapper.
Editor's Note: Interested in more of Barry's perspective? Read his The Battle for Data Supremacy: The Cost of Ignoring XML