Getting to "Zero Trust" architecture and philosophy

---

In PMO school, they teach you that trust is everything when building a successful project team.

Fair enough.

But now comes "Zero Trust", and the "Zero Trust Architecture" which is more like a philosophy than an architecture. And, of course, the acronyms: ZT and ZTA.

I don't know if NIST (*) coined this phrase, 'zero trust', but they have a proposed zero trust architecture you can read about here. 

Motive

The motive for developing ZTA was a realization that security threats to an enterprise's intellectual property (IP), whether corporate proprietary or government classified, are more often now inside the perimeter of a security firewall. Indeed, with the proliferation of remote working, the 'cloud, and 'bring-your-own-device (BYOD), the very idea of a perimeter is somewhat bye-the-bye. And so IP protection can no longer just be a matter of a security firewall around the enterprise.

Philosophy

So if you are philosophically in touch with 'zero trust', the idea is that every element of IP is subject to an enforced need-to-know, and an enforced limitation on copy and dissemination. The perimeter really no longer exists; a pass through the perimeter, even if existent, is relatively unproductive because of ZT gates on the IP.

The idea is to move from protecting a perimeter or a network segment to protecting the actual resource that is the IP of the enterprise. In effect, it is realized that there will be persistent active threats in the network; the security objective is to block them from accessing the actual IP.

ZT according to NIST

NIST says this: "Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network- based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows.

ZT is not a single architecture but a set of guiding principles for workflow, system design and operations that can be used to improve the security posture of any classification or sensitivity level. Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.  

Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. 

Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud- based assets that are not located within an enterprise-owned network boundary. Zero trust focus on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource."

NIST continues: 

"In this new paradigm, an enterprise must assume no implicit trust and continually analyze and evaluate the risks to its assets and business functions and then enact protections to mitigate these risks. In zero trust, these protections usually involve minimizing access to resources (such as data and compute resources and applications/services) to only those subjects and assets identified as needing access as well as continually authenticating and authorizing the identity and security posture of each access request."

Their conclusion:

"When balanced with existing cybersecurity policies and guidance, identity and access management, continuous monitoring, and best practices, a ZTA can protect against common threats and improve an organization’s security posture by using a managed risk approach.

_______________

(*) NIST: National Institute for Standards and Technology

 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

A comment on Architecture

---

"Architecture" has been in the PM-domain commentary more and more as rapid and flexible methodologies compete with more experienced ideas.

• It's been said, correctly, that architecture is where functional utility is addressed first (*)
• And it's been said, again correctly, that architecture generally imposes, usually conforms to, and applies the construction and integration rules for the domain of the project. (**)
• It's been said, repeatedly by me and others, that every project has architecture (and an architect) even if somewhat buried in other tasks and roles, because everything virtual or real has an architecture

But beyond rules and utility there are myriad components to architecture

• It expresses the art contained within the domain. In software, there is definitely art!
• It expresses the culture of the context in which the product or outcome will live
• It provides coherence and organization to the entity under development

Architecture and system engineering share a lot of the same goals for organization, coherency, and predictable performance. 

• System engineering focuses hard on interoperability of the sundry pieces and parts, making interfaces work smoothly, and being the keeper of the flame of cybernetics, anti-fragile, and anti-chaos. 
• And system engineering often morphs into system test for validation and verification.
• Whereas architecture often morphs into softer elements such as appealing design and fit-to-culture.

All said, as long as what you are building is itself divisible -- and pretty much everything above the atomic level is -- then there are both architectural considerations of integration and system engineering choices at interfaces.

What about rapid and evolving methodologies?

These usually are focused at a level below architecture and system engineering. Usually the focus is on rapid or evolutionary development. In the case of Agile methods, there is a lot of flexibility allowed within the general constraints of interfaces. Architects and SEs work at the black-box level; Agilists work on the internal white-box solution

____________________

(*) "Utility" is the measure of effective value vs actual value. If you don't like it, if you can't live with it, or if it means little to you, it has little utility to you, although others may find its actual value quite satisfactory. The classic explanation is a poor person with $10 in their pocket vs a rich person with $10. The utility of $10 to the poor person is very much more than it is to the rich person.

(**) One only has to look into the architecture issues of the Sydney opera house to appreciate how the architect pushed conformity to construction rules to the limit 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Sketching out the architecture

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it."

Box model

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr. Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

Buy them at any online book retailer!

What say: Architecture?

---

So, we occasionally get silliness from serious people:

" ......  many enterprise architects spend a great deal of their time creating blueprints and plans based on frameworks.  The problem is,  this activity rarely leads to anything of genuine business value because blueprints or plans are necessarily:

Incomplete – they are high-level abstractions that omit messy, ground-level details. Put another way, they are maps that should not be confused with the territory.

Static – they are based on snapshots of an organization and its IT infrastructure at a point in time.

Even roadmaps that are intended to describe how organisations’ processes and technologies will evolve in time are, in reality, extrapolations from information available at a point in time.
The straightforward way to address this is to shun big architectures upfront and embrace an iterative and incremental approach instead"

That passage is dubious, as any real architect knows, though not all wrong, to be sure:

• Yes, frameworks are often more distraction than value-add; personally, I don't go for them
• Yes, if your blueprints are pointing to something of no business value, then if that is really true, change them or start over... simple common sense ... but let it said: you can describe business value on a blueprint!
• No, high level abstractions actually are often quite useful, starting with the narrative or epoch story or vision, all of which are forms of architecture, all of which are useful and informative. It's called getting a view of the forest before examining trees.
• Yes, abstractions hide detail, but so what? The white box detail can be added later
• Yes, roadmaps obsolesce. Yes, they have to be kept up to date; yes, sometimes you start on the road to nowhere. So what? If it doesn't work, change it. 

I think the agile principle "... the best architecture emerges ..." which is silliness writ large is the influence. We should put that aside, permanently. Why: because many small scale architectures simply don't scale.

Take, as just one example a physical story board or a Kanban board of sticky notes in a room somewhere. That architecture works well for a half dozen people. Now, try to scale that for half a thousand... it really doesn't scale. The technology doesn't scale.. you need an electronic database to support 500 people; the idea of all independent stories doesn't scale unless you add structure, communications, protocols, etc, all of which are missing or unneeded at small scale.

To the rescue: Here's another recent passage from another serious person who has a better grip:

One conjecture we arrived at is that architects  typically work on three distinct but interdependent structures:

1. The Architecture (A) of the system under design, development, or refinement, what we have called the traditional system or software architecture.
2. The Structure (S) of the organization: teams, partners, subcontractors, and others.
3. The Production infrastructure (P) used to develop and deploy the system, especially important in contexts where the development and operations are combined and the system is deployed more or less continuously.

---

Buy them at any online book retailer!

Lessons on architecture

---

I love architecture, though I'm not an architect, and never studied architecture. Of course, I love system architecture, which is both different from building and construction per se, and identical -- because a building is a system, just as any other such integrated structure is a system.

Frank Gehry is one of Canada-America's more esteemed architects.  He does projects around the world.  The picture is of the museum in Bilbao, Spain.  Of course, Gehry always designs some pretty unusual stuff, having said things like this about his projects (take note: these ideas scale pretty well; there's nothing inherently 'small' or 'large' about any of them):

• Models: thorough with the envisioning and conceptualization, Gehry often building 100 models before he 'sees' it.  (Spiral method, anyone?)
• Customer commitment: makes a priority of customer buy-in, and in the end, the customer never regrets -- editorial: never say never; and the ultimate buy-in may be the embedded customer
• Functional success: Wow! it has to work.  Has everyone heard and internalized that one? It's pretty hard to general value, even intangible value like 'esteem', if the thing doesn't work, or the roof leaks, etc
• Practical to build: You have to be able to actually build it:  technologically feasible and feasibly economical (perhaps we should revisit the Sydney opera house--not a Gehry design -- for a lesson in 'can you build it' and if you can, can you afford to build it?), and
• Other people's money: It has to meet a budget! (Back to PM 101, and the consequences of "other people's money")

Actually, on these last two points, another flamboyant architect, Frank Lloyd Wright, never actually got it.  Many of his buildings didn't work (roofs and windows leaked, for one thing), and he rarely (some say never) met a budget.  And he didn't miss closely, he missed by a mile!

Some of these problems are like any 'new to the world' endeavor: stuff happens!  But some is just downright delusional or deliberately deceptive.  Some advice just never gets old: Buyer beware!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The scope thing ...

---

Does everybody buy this?

Scope is defined this way:
 • Scope is all the things we must do, all the things we want to do, and all the
things we actually do
 • Backlog is the scope parsed into work units, stories, use cases, tasks, and
the like
 • Architecture is the scope mapped into form and function

I hope you're buying; that's the way I wrote in the 2nd edition of "Project management the agile way"

Of course, "... all the things we must do, all the things we want to do, and all the
things we actually do" probably don't fit in v1.0 ... that's why we have v2.0. That's why we do release planning and that's why we parse the backlog to fit project capability and capacity.

Waxing on: There  are  some  must-do's  that  influence  scope— must-do's  as  a  matter  of
governance and must-do's as a matter of custom and expectation.

Now, the lecture: Projects must adhere to standards that have become generally accepted practices; processes and protocols must be applied in a manner that is consistent with certifications; and projects must meet the unspoken demands of the market that, over time, have become routinely expected—demands for reliability, availability,  compatibility,  responsiveness,  and  eco-friendliness,  to  name  a few.

Bottom line: Scope is too important to be left to the customer/user. There's a lot stuff to consider for which they don't bring the clues

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Architecture ... more about this

---

“Architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision” … SEI

Who can argue with those words?

Among the agile methodologies that emphasize architecture, in contravention of agile principle , which is pretty much nonsense, I like DAD (Disciplined Agile Delivery) which is more or less where Scott Adler's personal journey in agile has led him.

Architecture in DAD pretty much begins with the idea of “enterprise architecture”:
•    Enterprise architecture (EA).  An organization’s enterprise architecture consists of the various structures and processes of an organization, including both technical structures and processes as well as business/domain structures and processes.  There is always an enterprise architecture, even when it isn’t documented.

Even though DAD allows for the EA not to be documented, a role is presumed called the Enterprise Architect who has responsibility for the enterprise architecture in whatever form it takes. Built into DAD is a purposeful collaboration between project architects—which could be a team of architects at both project office and agile teams—and the enterprise architect.

An architect team workflow is envisioned with four major tasks:
1.    Envision initial architecture. The outcome is most often a model of the product or process as it will be integrated into the business. Although there could be iteration of this model, the initial model more or less sets the vision
2.    Collaborate with business stakeholders. This task is an on-going level of effort which has communication at its core
3.    Collaborate with IT stakeholders. Similar to step 3, but targeted more directly at those who have responsibility for the IT infrastructure which will support the product or process over the life cycle.
4.    Evolve architecture assets. These assets could include artifacts architecture models, reference architectures, development guidelines, white papers, and structured analysis.

DAD architecture value-add
Architecture in DAD is perhaps best summarized by the value-add given as these five reasons for why have a planned project effort on architecture:
1.    Common architecture enables agile teams to focus on value creation.
2.    Common technical guidance enables greater consistency.
3.    Agile architectures enable disaggregation
4.    Common infrastructure enables continuous delivery
5.    Enterprise architecture scales agile

Need more on agile architecture? Did I mention my upcoming 2nd edition to "Project Management the Agile way: making it work in the enterprise"?

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The architecture thing...

---

So, we occasionally get silliness from serious people:

" ......  many enterprise architects spend a great deal of their time creating blueprints and plans based on frameworks.  The problem is,  this activity rarely leads to anything of genuine business value because blueprints or plans are necessarily:

Incomplete – they are high-level abstractions that omit messy, ground-level details. Put another way, they are maps that should not be confused with the territory.

Static – they are based on snapshots of an organization and its IT infrastructure at a point in time.

Even roadmaps that are intended to describe how organisations’ processes and technologies will evolve in time are, in reality, extrapolations from information available at a point in time.
The straightforward way to address this is to shun big architectures upfront and embrace an iterative and incremental approach instead"

That passage is dubious, as any real architect knows, though not all wrong, to be sure:

• Yes, frameworks are often more distraction than value-add; personally, I don't go for them
• Yes, if your blueprints are pointing to something of no business value, then if that is really true, change them or start over... simple common sense ... but let it said: you can describe business value on a blueprint!
• No, high level abstractions actually are often quite useful, starting with the narrative or epoch story or vision, all of which are forms of architecture, all of which are useful and informative. It's called getting a view of the forest before examining trees.
• Yes, abstractions hide detail, but so what? The white box can be added later
• Yes, roadmaps obsolesce. Yes, they have to be kept up to date; yes, sometimes you start on the road to nowhere. So what? If it doesn't work, change it. 

I think the agile principle "... the best architecture emerges ..." which is silliness writ large is the influence. We should put that aside, permanently. Why: because many small scale architectures simply don't scale.

Take, as just one example a physical story board or a Kanban board of sticky notes in a room somewhere. That architecture works well for a half dozen people. Now, try to scale that for half a hundred... it really doesn't scale. The technology doesn't scale.. you need an electronic database to support 50 people; the idea of all independent stories doesn't scale unless you add structure, communications, protocols, etc, all of which are missing or unneeded at small scale.

To the rescue: Here's another recent passage from another serious person who has a better grip:

One conjecture we arrived at is that architects  typically work on three distinct but interdependent structures:

1. The Architecture (A) of the system under design, development, or refinement, what we have called the traditional system or software architecture.
2. The Structure (S) of the organization: teams, partners, subcontractors, and others.
3. The Production infrastructure (P) used to develop and deploy the system, especially important in contexts where the development and operations are combined and the system is deployed more or less continuously.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Fix the architecture or the leaky windows?

---

One of the agile principles is to let -- or even encourage -- architecture emerge in its own time and in its own way from the work of the teams. The principle alleges good architecture will come about this way.

Perhaps, but too much risk for me. Good architecture comes from good architects, though they often miss the small stuff on the margin.

Frank Lloyd Wright was a brilliant American architect of the 20th century, but, in almost everything he did, the windows leaked.

The post-WW II suburban "bedroom" towns of the 1950's and 1960's were sprawls of cookie-cutter homes, efficiently built in just a few models that repeated on every street, void of any appealing architecture, and the windows never leaked.

And, so what do we make of this? Is there something actionable here?

Yes: there is a choice to be made, and with that choice an investment and a risk. The choice is whether to pay -- or not -- for good architecture, knowing that its quality is strategic, defining, and discriminating; knowing it will return value many times over.

But, at the same time, the risk is that we are going to have to fix the windows.

Many good architects may get too close to the edge of "it can't be built" as they reach for the discriminating design.

---

Frank Lloyd Wright was an American architect and interior designer who designed the Solomon Guggenheim Museum in New York City, which is located on the city’s popular Fifth Avenue. Wright was acknowledged in 1991 by the American Institute of Architects as being the greatest American architect of all time See: www.constructionmanagementschools.net/blog/2010/10-essential-architects-of-the-twentieth-century/

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Sketching architecture, etc

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it.

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Do the math!

---

Heard about "merge bias"?

Actually, some of us have. And, probably to everyone's relief it's not one more in a long list of cognitive biases.

So, here's the problem: You have two or more predecessor activities (see also: gates, tasks, swim lanes, projects) joining independently to form a finish-to-start dependency on a successor activity. If the predecessors are both/all supposed to finish (or get DONE) at the set time to set off the successor activity, should you worry?

Yes, you should. Where the activities merge, like at a gate, there is a bias toward having to shift the schedule to the right (see: schedule slip) in order to maintain confidence in the schedule end date.

In other words, by example for two paths, if there is a 50-50 chance of both paths finishing independently together, then there is only 1 chance in 4 that the successor will start on time:

Activity	1.On time	1.Late
2.On time	On time	Late
2.Late	Late	Late

Saying it with confidence: The graphic gets your attention, but it's really limited for understanding what's going on. It's a matter of 'confidence'. In the case illustrated, the proper way to understand this is:

"Your confidence that the successor can start 'on time or earlier' is 25% or less. Your confidence that the successor task will start late is 75%, or more"

How much earlier? How much later? You don't know from what I've said so far, but you can get a handle on it with a Monte Carlo simulation.

Do the math: If I replace the labels "on time" and "late" with quantitative probabilities, you can see that the probability in each cell is the product of the row-column intersection. To wit: 0.5 * 0.5 = 0.25

So, your challenge as schedule architect is to increase the confidence of the successor F-S. How to do it? Here's an idea: re-architect the schedule from 2 paths to 3 simpler paths, each with  higher probabilities on account of their simplicity.

Now the graphics for three paths of different probabilities gets too awkward  because now you need a  figure of 8 (2^3) intersections rather than a figure of 4 (2^2) intersections. Best that you stick with the quantitative probabilities.

You might get something like this, as an example, of three independent activities (probability shown as on-time, so p[late] = 1 - p[on-time]):

• Activity 1: 70%
• Activity 2: 65%
• Activity 3: 75%

The joint probability of on-time is their product: 34%, slightly better than the 25% figure of the two lower probability higher complexity paths.

Now, of course, this re-architecture can go the wrong way: the improvement in probability has to be fairly large to overcome the three path merge bias. Nonetheless, this option is available for risk managers and schedule architects.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

If you can't draw it... (and other system engineering stuff)

---

Many creative people will tell you that new ideas begin -- often spontaneously -- with a mind's sketch that they then render in some kind of media.

Fair enough -- no news there. We've talked about storyboards, etc before.

But then the heavy lifting begins. How to fill in the details? Where to start?

My advice: Draw it first.

If you can't draw it, you can't build it!

And so the question is begged: What's "it"

Three elements:

1. Narrative
2. Architecture
3. Network

And, one more for the PM:

• Methodology

Digression: My nephew reminds me that now we have 3-D printing as a prototype "drawing" tool. Indeed, that's his job: creating 3-D prototypes.

Narrative: (an example)
Bridge stanchion with strain sensor and sensor software

Architecture:
Let's start drawing: Actually, I like drawing with boxes. Here's my model, beginning with the ubiquitous black box (anyone can draw this!):

Black Box

Of course, at this point there is not much you can do with this 100% opaque object, though we could assign a function to it like, for example: bridge stanchion (hardware) or order entry shopping cart (software)

And so given a function, it needs an interface (blue); some way to address it's functionality and to enable its behavior in a larger system context:

Interface

And then we add content (white):

Content

Except, not so fast! We need 'room' for stuff to happen, for the content to have elasticity for the unforeseen. And, so we add a buffer (grey) around the content, but inside the interface, thus completing the model:

• Black: Boundary
• Blue: Interface or API
• Grey: Buffer
• White: functional content

You could call this an architecture-driven approach and you would not be wrong:

1. First, come the boxes:

• Define major functional "boxes"... what each box has to do, starting with the boundary (black): what's in/what's out. This step may take a lot of rearranging of things. Cards, notes, and other stories may be helpful in sorting the 'in' from the 'out'. If you've done affinity mapping, this boundary drill will be familiar.
• Our example: three boxes consisting of (1) bridge stanchion (2) strain sensor (3) sensor software

Then comes the interface:

• Then define the major way into and out of each box (interface, I/F, blue). If the interface is active, then: what does it do? and how do you get it to do it?

And then comes the "white box" detail:

• The buffer, grey, captures exceptions or allows for performance variations. In effect, the buffer gives the content, white, some elasticity on its bounds.
• And then there is the actual functional content, to include feature and performance.

Network

2. Second big step: networks of boxes

• Think of the boxes as nodes on a network
• Connect the 'black' boxes in a network. The connectors are the ways the boxes communicate with the system
•  Define network protocols for the connectors: how the interfaces actually communicate and pass data and control among themselves. This step may lead to refactoring some of the interface functionality previously defined.
• That gets you a high-level "network-of-boxes" . Note: Some would call the boxes "subsystems", and that's ok. The label doesn't change the architecture or the functionality.

3. Third big step: white box design.

Define all the other details for the 'white box' design. All the code, wiring, and nuts and bolts marterials to build out the box.

• Expect to refactor the network as the white box detail emerges
• Expect to refactor the white box once development begins. See: agile methods

And, not last: Methodology:

The beauty of this model is that each box can have its own methodology, so long as interfaces (blue) and boundaries (black) are honored among all boxes. In other words, once the boundaries and interfaces are set, they are SET!

The methodology can then be chosen for the white box detail: perhaps Agile for the software and some form of traditional for the hardware. This heterogeneous methodology domain is workable so long as there is honor among methods:

Interfaces and boundaries are sacrosanct!

Now What?
Estimate the work (yes, estimate: you really can't start off spending other people's money without an estimate); segment and sequence the work; and then build it, deliver it, and you are DONE!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

My backlog is blocked!

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling the culprit

Coupling? Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transferrence, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transferrence of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's  Critical Chain method for more about decoupling with buffers

But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in environment A without strongly influencing environment B; this is sort of a "us vs them" approach, some might say stovepiping.

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

Bookmark this on Delicious

About architecture

I probably misnamed this posting. It's as much about architecture as it is about the architect.

In the fifteenth century, an architect was a liberal arts guy with an eye for structure, symmetry, and form. Consider this passage from a description of the time:

A true architect can't be just a master of his trade. He had to be a well-rounded person....let him be educated, skillful with the pencil, instructed in geometry, know much about history, have followed the philosophers with attention, understand music, have some knowledge of medicine, and be acquainted with astronomy and the theory of the heavens".

(Of course, the pencil was not invented until late 16th century, so this passage from 100 years earlier is translated from the Latin or the Italian with some flourish)
And then we learn this:

Architecture is the defining art. It creates civilization. It constructs homes and lays out cities...It designs temples, revealing the will of the gods...It produces machines, guaranteeing victory in time of war and prosperity in time of peace... It builds empire

---

I will say this: some of my best software people were music majors. The poetry of music fits well the poetry of software.

Someone who builds empire!
I always wanted one of those. (I got no closer than being someone's Vice President, and we didn't have much of an empire to speak of)

But on a serious note, you can see these passages at work in some of the world's most interesting buildings (See: Opera House, Sydney), but also in some of the most elegant digital processing, to say nothing of the beauty of the recent Apple products.

Architecture is alive and well all around us and in every project, whether we acknowledge it or not. Everything we design or build has architecture--no structure, tangible or intangible, is without it--and every structure, whatever it is, is probably for the better if an architect has weighed in.

And, I've always advocated an architect on the project team. Now, I'm wondering how I ever did without one.

---

Quotes taken from "Da Vinci's Ghost" by Toby Lester



Bookmark this on Delicious

Agile oscillators

When I first got out of engineering school, one of my first projects was to build an oscillator. An oscillator is a device--should I call it an object?--with "just enough" reinforcing feedback of output back to input, with the feedback arrival timed just so, such that there is a constantly varying cyclic output, swinging first one way and then the other.

The nature of the varying cyclic output can be quite jarring, or it can be nuanced and smoothed out:

Now, along comes Agile, and my thoughts go back to the oscillator. And, I'm not the only one. Jim Highsmith has been thinking about the same thing. The architecture (stucture and behaviors) of all agile methods includes feedback, mostly from customers/users, but also from sponsors/stakeholders. The mandate for agile teams is to respond, and be responsive, to feedback. That is, a sample of output--in the form of user experience--becomes a part of the input to the deliberations of the agile team.

Now, if the feedback is phased (timed) one way, it will stablize the iteration. Change the timing a bit and it will destablize the iteration and cause oscillations. In effect, the team builds one thing, only to find out--in the wrong timing--that the customer has changed their mind; the team responds to the change. But, meanwhile, the customer is experiencing the wrong (earlier) thing and seeks correction. Ooops! the team is driven back, or a different way.

If the timing is never corrected, the iteration becomes oscillatory and really nothing gets done.

Time for the project manager to step in and call a halt and dampen the oscillations. Everyone needs to take an Iteration 0 break to do a little reflection and get the timing reset. Maybe a spike needs to be inserted to allow for some non-deliverable prototyping or modeling.

In any event, oscillations can not be allowed for more than a cycle, perhaps two. If not naturally damped out, the PM must take action!

Bookmark this on Delicious

Quantum computers in the offing?

... the team has demonstrated that it is possible to take photons from two disparate sources and render these particles partially indistinguishable ... [suggesting] in principle that they can connect various types of hardware devices into a single quantum information network.

This bit of quantum news was recently reported by the National Institute of Standards and Technology (NIST) on their blog. And, actually you could say it's a breakthrough that might lead to quantum computers and a whole new era of amazing computational power.  Who knows where that might lead?

I can't wait to hangup the silicon laptop for a photon computer!

Bookmark this on Delicious

Agile and architecture

If you accept this fact—that the choices you make today will most certainly be wrong in the future—then it relieves you of the burden of trying to future-proof your architectures.

—Richard Monson-Haefel, author of 97 Things Every Software Architect Should Know

It continues to amaze how some agile advocates fail to recognize, and even deny, that when you put together something as simple as two objects, you've created architecture (definition: a description or specification of behavior, appearance, structure, and relationship of and among components).

Thus, when some agilists say they need not concern themselves with architecture, or that it is not all that important, I wonder what planet they are on. Attention: even if it's not written down, or put to powerpoint, a system (two objects, or more) has architecture, and their behavior jointly may well be important and worthy of evaluation.

And yes, I'm aware of this agile principle: "The best architecture, requirements, and designs emerge from self-organizing teams", though I'm not alone saying this principle is decidely limited to the small bore and fraught with scalability issues.

My attention was drawn to a posting by Phillipe Kutchen entitled "Agility and architecture koan" for two reasons:,

1. I did not know what "koan" means; I thought I might find out.
2. He quote a truly mindless statement from a LinkedIn group: “Self-organizing teams can decide everything by themselves. So they don’t need an architect.”

• The former means paradox, or non-sensical statement or question
• The latter is just mindless, but to give the widest possible latitude, perhaps the author was referring to a dedicated position called "architect" and not trying to say that team members should not be architects, or worse: there's no architecture per se.

Anyway, I am in the Kutchen school. In a book I wrote about agile in enterprise projects, and in an article Kutchen wrote for Software (an IEEE publication), Agility and Architecture: Can They Coexist?, we both expound on the obvious: architecture is a matter of context, project context, but all projects and all systems possess architecture, whether you want it or not.

And, of course, even unabashed and credible agilists like Dean Leffingwell, author of numerous well regarded books and articles on software practices in general and agile practices specifically, says that as a project becomes more than the scope of one team working:

For developers, architects, and businesspeople who have experience building large-scale systems and portfolios consisting of systems, products, and services—with the extensibility and scalability a successful solution demands—a solely emergent architecture is counter to our experience. We know that some amount of architectural planning and governance is necessary to reliably produce and maintain such systems. Individual teams, products, and programs may not even have the visibility necessary to see how the larger, enterprise system needs to evolve. It can’t simply emerge. Something has to tie it all together......


Even minor, system-level redesigns can cause substantial rework for large numbers of teams, some of whom would otherwise not have to refactor their module. It is one thing for one team to redesign their code based on lessons they have learned; it’s quite another to require ten teams to do so based on another team’s lessons learned.

And no less an eminence than XP's Kent Beck writes:

Architects on an XP team look for and execute large-scale refactorings [and] write system-level tests that stress the architecture....

While the system is little, the architect makes sure the system has just the right little architecture.

In another space, Computing Now, Maurizio Morisio provides a half-dozen links to reputable thinkers about the role of architecture, architects, and the intersection with agile methods.  Take a few minutes, and read all about it!

Source:
Chapter 20 "Agile Achitecture" from Dean Leffingwell(2010). "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise",  Addison-Wesley Professional. Kindle Edition

Chapter 10, "The Whole XP Team" from Kent Beck (2004)"Extreme Programming Explained: Embrace Change" Second Edition; Addison-Wesley

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Complexity anyone?

John Biaz, a mathematician rather than a project manager, asks some provocative questions from time to time that are of interest to us. The latest in his post on complexity:

What can you do with just a little information?

• Bill Gates’ first commercial success was an implementation of a useful version of BASIC in about 4000 bytes;

• The complete genetic code of an organism can be as short as a few hundred thousand bytes, and that has to be encoded in a way that doesn’t allow for highly clever compression schemes.

This from Wikipedia:

Recent computer hardware advancements include faster processors, more memory, faster video graphics processors, and hardware 3D acceleration. With many of the past’s challenges removed, the focus .... has moved from squeezing as much out of the computer as possible to making stylish, beautiful, well-designed real time artwork

On the other hand, Baez's friend Bruce Smith produced this video (sans hardware infrastructure) in 4KB (that's a rounding error on a rounding error in most programs today). So, don't say it can't be done; don't accept bloat; be lean!

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Frank Gehry on projects

I love architecture, though I'm not an architect, and never studied architecture. Of course, I love system architecture, which is both different from building and construction per se, and identical because a building is a system just as any other such integrated structure is a system.

Frank Gehry is one of Canada-America's more esteemed architects.  He does projects around the world.  The picture is of the museum in Bilbao, Spain.  Of course, Gehry always designs some pretty unusual stuff, but in an interesting interview on cnn.com/gps for September 4, 2011, he says about his projects:

• He's very thorough with the envisioning and conceptualization, often building 100 models before he 'sees' it.  (Spiral, anyone?)
• Everything he does has customer buy-in, and in the end, the customer never regrets (Sounds like an embedded agile customer)
• The building has to work functionally (wow! it has to work.  Have the ERP guys heard that one?)
• You have to be able to actually build it, meaning it has to be technologically feasible and feasibly economical (perhaps we should revisit the Sydney opera house--not a Gehry design), and
• It has to meet a budget! (Back to PM 101, and the consequences of "other people's money")

Actually, on these last two points, another flamboyant architect, Frank Lloyd Wright, never actually got it.  Many of his buildings didn't work (roofs and windows leaked, for one thing), and he rarely (some say never) met a budget.  And he didn't miss closely, he missed by a mile!

Some of these problems are like any 'new to the world' endeavor: stuff happens!  But some is just downright delusional or deliberately deceptive.  Some advice just never gets old: Buyer beware!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

KISS, again

KISS: Keep it simple, stupid!

Is there anything new to report about simplicity, or its virtues?

Perhaps.

To get the conversation started, consider "Fifteen ways to shut down a Windows laptop" 

On the serious side, I happened upon the book "Ten Laws of Simplicity" by John Maeda. You can download the book on Kindle for $12, but here's the gist:

But of course, there are many learned treatise' on this topic.  For instance, David Pogue writes about gadgets, and his 'cause celebre' is also simplicity.  In a TED talk on this , Pogue's "rules" (rules is probably an overstatement) are:

• People like to surround themselves with unnecessary power
• If you improve a piece of software often enough you eventually ruin it
• One approach to simplicity is 'let's break it down'. (but disaggregation leads to its own form of complexity, e.g. the trees rather than the forest)
• Violate consistency in favor of intelligence (don't alphabetize US on a list of 200 countries for US users)
• Easy is hard: pre-sweat the details
• Simplicity sells

Pogue actually mixes in some humor with his talent for piano and song:

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.