Learning to Think About Systems Through Frameworks and Methodologies

I became interested in frameworks and methodologies early in my career, starting with a systems development methodology called Structured Analysis and Design (SA/SD).

Ed Yourdon, a pioneer in the field of computer science, led the development of SA/SD at a time when managing large systems was becoming increasingly problematic.

In earlier times, computational resources were scarce, even by today’s standards with AI systems and HPC workloads.

Large computer systems were also brittle, resistant to many of the types of changes we now often take for granted, given modern tooling, automation, and software-defined components. 

How We Approached Large Systems Early On

Although it’s an oversimplification, I think the earliest structured methods were primarily attempts to combine rigorous requirements definition with documentation methods for the purpose of avoiding the pain of changing things downstream.

But change was inevitable.

They essentially aimed to decompose systems functionally and technically, and to document requirements.

SA/SD variants would typically start at a high level, establishing context, then decomposing that perspective, or view, into data flows, which were then followed by logical and physical designs, primarily using structured diagramming techniques. 

When Programming Enters the Systems Development Process

At some point, you made the jump to writing code, to making a computer do something. But it was never obvious to me at what point that should be. The path was simply not that direct.

But I learned early on that studying these frameworks—and there are many—is a good way to understand the engineering of large systems from different perspectives.

The Limitations of Frameworks and Methodologies in Enterprise Architecture

The problem with these frameworks and methodologies is that they are not a substitute for thinking, just recipes that can be followed explicitly. You have to mine them, take what’s useful, and move forward with a collective approach that’s appropriate for your needs.

For Enterprise Architecture, that can include architecture frameworks like TOGAF, but also more general ones like COBIT and CMMI, as well as more specifically defined frameworks like NIST CSF and ISO/IEC 27001, to name a few. 

Picking back up from the post, Creating the Structural Foundation for Enterprise Architecture, we’ll look at an unusual starting place for establishing the structure, ownership, and accountability needed for effectuating Enterprise Architecture.

It’s a well-worn standard in IT Operations called ITIL, the Information Technology Infrastructure Library. We’ll cover that in the next article, Enterprise Architecture, ITIL, and the Architectural Role of Asset Management.

Notes:
1. Image created with OpenAI’s ChatGPT.