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:
- What: This perspective addresses the business concepts, including the essential business goals, processes, entities, and their relationships.
- How: It focuses on the processes and activities that describe how the business operates and functions.
- Where: This perspective refers to the locations where the business operates, including physical locations, virtual spaces, or areas of the enterprise’s influence.
- Who: It involves the stakeholders within the enterprise, including roles, responsibilities, and organizational structures.
- When: This perspective deals with time-related aspects, such as events, timelines, and the sequencing of activities or processes.
- 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:
- What is the problem to solve, the requirements and/or scope
- How is the Design, but the Who needs to come first.
- Where is the Deployment
- Who is the Solution, the things relevant to solving the problem, requirements, and scope
- When is the schedule, release, time-to-market
- 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:
- 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.
- Container Diagram (Level 2 - Container Context): It zooms into the system to illustrate high-level containers (e.g., applications, databases, services) and their interactions.
- 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.
- 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
Post a Comment