Frameworks vs Delivery


In this post, we are going to touch on, briefly and I mean briefly, several Frameworks to consider pertain to getting into our Software and Systems Architect Series on our UML Operator Channel. We will refer back to this post during the course of our demonstrations.

To Begin...Do Not Get Carried Away!

When the process is lost, there is good practice.
When good practice is lost, there are rules.
When rules are lost, there is ritual.
Ritual is the beginning of chaos.

TOGAF

The first is TOGAF, The Open Group Architecture Framework. I recommend studying and achieving a certification in TOGAF. In my opinion, this was the best investment I made over my careers. TOGAF is a widely used framework for enterprise architecture. It offers a methodology and set of supporting tools for developing a wide range of architectures.

I couple TOGAF with the idea or concepts of C4 Modeling, BPMN, SAFe, and even PMBOK.

Zachman Framework

The Zachman Framework is an approach to enterprise architecture that provides a structured and comprehensive way to view and manage the elements of an enterprise. It was developed by John Zachman in the 1980s and has since become a widely recognized and utilized framework for organizing architectural artifacts.

The six perspectives in the Zachman Framework are:

  1. What: This perspective addresses the business concepts, including the essential business goals, processes, entities, and their relationships.
  2. How: It focuses on the processes and activities that describe how the business operates and functions.
  3. Where: This perspective refers to the locations where the business operates, including physical locations, virtual spaces, or areas of the enterprise’s influence.
  4. Who: It involves the stakeholders within the enterprise, including roles, responsibilities, and organizational structures.
  5. When: This perspective deals with time-related aspects, such as events, timelines, and the sequencing of activities or processes.
  6. Why: It delves into the motivations and goals behind the enterprise’s actions, strategies, and decisions.

However, I tend to use these adverbs a bit differently. For me:

  1. What is the problem to solve, the requirements and/or scope
  2. How is the Design, but the Who needs to come first.
  3. Where is the Deployment
  4. Who is the Solution, the things relevant to solving the problem, requirements, and scope
  5. When is the schedule, release, time-to-market
  6. Why is too the motivation and this is where ArchiMate is thought of.

DoDAF (Department of Defense Architecture Framework)

Similar to FEAF, but tailored for the U.S. Department of Defense, it provides a comprehensive approach to architecture development within the defense industry. DoDAF is structured around a set of viewpoints that offer different perspectives to describe the architecture of defense systems and capabilities. These viewpoints help stakeholders focus on specific aspects of the architecture, making it easier to communicate and understand complex systems within the DoD. Within each viewpoint, specific models are used to represent the architecture.

DoDAF defines data elements and relationships between them, creating a common language and structure for describing defense architecture across the DoD. This allows for consistency and interoperability between different components and systems within the defense enterprise.

However, for Viewpoints, I tend to fall back on TOGAF for my architecture approaches and delivery.

ArchiMate

As a visual modeling language for enterprise architecture, this provides a set of concepts to support the description, analysis, and visualization of architecture within and across domains.

ArchiMate is the modeling approach (framework) used in TOGAF and supported by "The Open Group". ArchiMate aligns with TOGAF's Architecture Development Method (ADM) and comprised of four verticals (Passive Structure, Behavior, Active Structure, and Motivation) covering four horizontals (Business Layer, Application Layer, Technology Layer, and Implementation & Migration).

ITIL (Information Technology Infrastructure Library)

The Information Technology Infrastructure Library (ITIL) is a widely adopted framework used for managing and delivering IT services effectively. It provides a set of best practices and guidelines for IT service management (ITSM), aiming to align IT services with the needs of the business.

Benefits:

  • Improved service quality and customer satisfaction.
  • Better alignment of IT services with business goals and strategies.
  • Enhanced efficiency and effectiveness in delivering IT services.
  • Clearer roles and responsibilities, leading to improved accountability and governance.

SAFe (Scaled Agile Framework)

A framework for scaling agile and Lean practices across multiple teams, providing guidance for large-scale software development projects.

I have to admit, when SAFe first came out, I was not a big fan. I already had problems with groups doing "Agile" and SAFe seemed to focus on large groups of people gather in one location, facing each other, and using 'paper and pen' to accomplish delivery. SAFe didn't appear to be safe to me, was more costly, and really was NOT "Agile". SAFe seemed half-baked.

However, there were at the time, and still are, many aspects of SAFe that were well done. For example, defining Agile Release Trains (ARTs), Roles (although confused stakeholders), Program Increments or PIs which set some guardrails, and laying out various levels of SAFe implementations (e.g., Enterprise, Large, Portfolio).

In SAFe, ARTs can go 10-12 weeks, whereas in Agile Sprints can span 1 to 4 weeks. Both support the notion of "iterations" which came about from Dr. Barry Boehm's Spiral Method from the late 80's.

BPMN (Business Process Modeling Notation)

While not a complete architecture framework itself, BPMN is a standard for graphical notation of business processes, often used in conjunction with other frameworks.

Business Process Model and Notation (BPMN) is a standardized graphical notation used to create visual representations of business processes. It provides a common language for business users, analysts, and stakeholders to understand, analyze, improve, and communicate complex processes within an organization.

In UML, this is a Graphical Notation, Process Modeling approach, contains Levels of Details, supports Collaboration and Interactions, covers Interoperability, and is well Standardized.

With BPMN, we consider BPEL (Business Process Execution Language). This is an XML-based language used for describing business processes that orchestrate web services and other software components to execute a series of coordinated tasks. BPEL enables the specification of executable business processes that can be deployed and run within a BPEL engine or runtime environment. It plays a crucial role in enabling automation, integration, and execution of complex, service-based business processes in various domains such as enterprise applications, cloud services, and more.

PMBOK

Though primarily focused on project management, PMBOK also offers valuable insights into project-related architectures and processes. PMBOK stands for the Project Management Body of Knowledge. It is a comprehensive guide published by the Project Management Institute (PMI) that provides a standard framework and best practices in project management. The PMBOK Guide serves as a foundational reference for project managers and practitioners worldwide.

While in most projects I have worked over the decades, the Developer is the most abused role with Project Managers a close second. Understanding the role of Project Manager(s) is critical in any delivery (I MEAN ANY!!).

PMBOK outlines five process groups—Initiating, Planning, Executing, Monitoring and Controlling, and Closing—and ten knowledge areas that encompass various aspects of project management, such as scope, time, cost, quality, human resources, communications, risk, procurement, stakeholder, and integration management.

There are so many important knowledge areas for any Project Manager (PM), such as Scope Management, Time Management, Cost Management, Quality Management, and list goes on. Without a good PM.

In Agile Methodologies, even SAFe, the idea of Project Management has been skewed. I have heard some organizations, lost in Agile vs Waterfall, say stupid things like, "We no longer need Project Managers". Then I watched them fail at Delivery more or less being "agile".

C4 Model

The C4 Model is a framework designed to help visualize and describe software architecture at different levels of abstraction, allowing for effective communication among stakeholders. It consists of a set of hierarchical diagrams:

  1. Context Diagram (Level 1 - System Context): This diagram provides an overview of the system and its surrounding environment, showing how it interacts with external entities.
  2. Container Diagram (Level 2 - Container Context): It zooms into the system to illustrate high-level containers (e.g., applications, databases, services) and their interactions.
  3. Component Diagram (Level 3 - Component Context): This diagram delves deeper into individual containers, showcasing the components that make up each container and how they interconnect.
  4. Code Diagrams (Level 4 - Code Context): These diagrams, though not strictly a part of the C4 Model, could represent specific code components or classes, providing a more detailed view.

My Conclusion

I go back to the KISS Principle (Keep It Simple, Stupid), or if you if want to be nice, Keep it Short and Simple. When it comes to delivering Systems and Software, I pull no punches.

I believe that every Architect should have knowledge around TOGAF. In Modeling, especially UML, there should be knowledge amongst Stakeholders around the art of BPMN. Teams should NOT get wrapped around the "Agile" hype and Waterfall (and other methodologies) are still beneficial concepts today. And the two most important roles in delivery are the Developer and Project Manager (regardless of their titles). In my opinion, the Client is the least important when it comes to "Delivery". The "Client" may hold the purse strings, but if they don't know their own business, they are a risk more than a benefit. --I am sure that statement will get me in trouble 😆.

Even in iterative methodologies there is still the need for linear sequential approaches to software development and project management. While the notion of "Projects" has evolved, the idea of "Programs" or "Product Realization" is still an important idea in any Enterprise or Small Company.

In Agile methodologies, including SAFe (Scaled Agile Framework), the terms "Theme," "Program," and "Project" represent different concepts within the context of organizing and managing work, especially in software development and project management.

In summary, Themes represent high-level objectives, Programs encompass related projects towards achieving those objectives, and Projects are individual endeavors with specific objectives and deliverables. Agile and SAFe frameworks provide the flexibility to manage work across these different levels of granularity, allowing organizations to align their efforts with strategic goals while maintaining flexibility and adaptability in execution.

However, the "objectives" are the key to "Delivery" IMHO. Bottom line, we still have Programs and Projects while we are agile in delivery. We still need "Project Manager" more than ever, whether you slap the title of "Scrum Master" to them or not. We must achieve repeatable and defined simple practices and processes. A "Frameworks" provide a means of achieving maturity and effectiveness in delivery.

Don't forget about "Stories" or "Story Telling". Stories, as an agile concept are valuable only if they are properly formed with acceptance criteria. If Stakeholders cannot write effective stories, your delivery is doomed.

Thus, what we cover in UML Operator Channel will use TOGAF with some ArchiMate, BPMN, and various Delivery methodologies done in iterative lifecycles. We may touch on the Capabilities Maturity Model (CMM/CMMi), but also touch on ITIL and even SPICE (Software Process Improvement and Capability Determination).

HAPPY MODELING!

Comments

Popular posts from this blog

Sparx EA and Open Collaboration

BPMN Diagram versus Sequence Diagram

MDA vs MDD