Bicycle Riding Lessons

I have always been a fan of bicycle riding. Energy from a renewable resource (my legs), fresh air, beautiful scenery sweeping by and speed.. what's not to like! Travel within the city in our younger days in India was entirely on bicycle.  Riding clunky and heavy bikes, with a luggage rack in the back, and an oil lamp hanging in front, the start of a bicycle journey was always heralded by the anticipation of reaching the destination.

So when my first born decided he wanted to learn to ride a bike, I was thrilled to share my love for economic travel and offered to teach him myself. We had bought a small bicycle that was on sale and came fully assembled.

We started off with preparations. I could not find a helmet that fit his small head so off we went to Target to get the helmet. I also got a pair of sturdy sneakers that would protect his feet from the pedals and the road. Just in case there was a emergency, I also packed a medical first aid kit with bandages, Neosporin, cotton and candy as a pacifier. I found an old electric inflator that ran off my car battery and pumped the tires of the bicycle to the required 60 psi. I tested the brakes to make sure they worked. Ensuring that the clip that secured the seat from going up and down was firmly in place, I went for a test ride hunched over the small bike on my driveway and pronounced the bike roadworthy and safe for my son.

We found a quiet parking lot in his elementary school over the weekend when no cars were parked or moving around. We found a kerb where he could stand and slip his legs over and around the seat and climb on.

I slowly pushed the bike forward with my son sitting on the seat. I held on to the bicycle to keep it vertical and steady as he began to pedal. And off he went as I ran by the side holding on. I helped steer the bike on a straight path and maneuvered it to return back to the curb where we left. I asked my son to apply both the front and rear brakes to stop the bike. The bike lurched to a stop and my son almost fell off but his feet could touch the kerbside and he was able to steady himself.

We made a few more passes and then came the decisive moment: his turn to ride alone without Dad holding the bike and running alongside. Were we ready? My first task was to move the battleground to the grass and away from the paved parking lot - my thought was that falling on grass was less painful and had fewer long term consequences if things did not go according to plan.  The next strategy was to build up enough speed from the takeoff that the extra speed itself would keep his bike vertical.

Everything went off according to plan. But. I had forgotten to show him how to stop and dismount. Just as the thought came to me, I saw my son fall to the ground in a thud at the end of the successful ride. We went back to the drawing board and practiced how to dismount while the bike was still coasting and not relying on the height of a kerbside.

Two more sessions and my son became an accomplished bicyclist - soon he was showing off by riding his bike hands free. He had finally mastered a very important skill and I was left with an architectural lesson from observing the whole process (we architects tend to complicate the simple and the obvious with complex terms and abstractions!)

Lesson number 1: Activity definitions depend on the Performer

The activity I was performing was Teaching My Son to Ride a Bicycle. The activity he was performing was Learning How to Ride a Bike. Notice that the verb phrase for the same activity changes when the performer changes - I was teaching and he was learning. Changing a viewpoint and concern changes the verb phrase and the metrics. I would be measuring my ability to teach while he would be measuring his ability to learn. We are both engaged in the same activity but goal-ed differently!

Lesson 2 Capability development has many solution paths

I was imparting (at least I thought so!) lifelong capabilities to my son. From a capability view, my son was acquiring the capability to Ride a Bike and its component capabilities (all of which are required) : (1) Mounting a Bicycle (2) Propelling a Bicycle Forward and (3) Dismounting from a Bicycle. We call the collection of capabilities all of which are required for achieving a larger capability, a capability configuration. Ride a Bike requires a capability configuration of at least three smaller capabilities. Of course, we have completely ignored the additional need for preparatory capabilities such as being able to inflate the tires, check the road-worthiness of the bikes (including the brakes) and the post riding capabilities of being able to shelter the bike from bad weather and moisture. All the stuff that seems to come in automatically as part and parcel of operating a vehicle.

Each of these capabilities could have been satisfied by solutions  in many ways: Mounting a bike can be performed by finding a high spot to climb on to the seat on a stationary bike or the rider can coast and stand on one pedal and then swing his legs over to mount.

Lesson 3 Activity Need drives Capability Development

Down the pike the capability of Ride a Bike the assumption is that my son would perform  the following specific chores (activities) (1) Bring groceries from the store (2) Ride to the public pool for taking a swim (3) Ride to a friend's house to hang out. The vision of what activities are enabled by capability drives the enthusiasm and excitement for acquiring capabilities. Investment in capability acquisition is an expensive exercise as we found out with his violin lessons and tennis lessons. Being able to map capabilities to the achievement of activities that are near and dear to his heart is a strong justification for that investment in his mind!

Lesson 4 Capability Shortsightedness

As my son grew older, the capability Ride a Bike was replaced by Drive a Car to perform these very same activities representing a Technology upgrade from Bicycle to Car. It occurred to me that maybe I should think of the capability Ride a Bike in broader terms as Travel Independently (of which Ride/Travel by Bike was a sub-type) and then I could accommodate today's bike travel with tomorrow's automobile travel to the future jet-plane travel he does today as an employee of a large corporation. By couching a capability in terms of current or the "then" technology made it limiting.

Lesson 6 Process Components

Clearly my concerns in various parts of the whole process were on different types of things:

In the PREPARE phase I was concerned with ensuring that the whole process would work. Part of the preparation was making a checklist of things to buy, things to check out and things to worry about, anticipating risks and threats,  and putting in place an environment where at the end of the day, my son would be able to successfully ride a bicycle.

In the PERFORM phase I was concerned with ensuring that I taught my son how to mount a bike, ride the bike in motion and then dismount after reaching the destination. He was interested in acquiring these skills also.

In the CLOSEOUT phase, we returned the bike back to the garage, hung it on the hook from the ceiling, kept away the helmets, and washed our arms and legs before we went back into the house.

In the CONTROL phase I was observing what my son was doing , making course corrections in the instructions, pointing out obstacles, gently guiding the bike's handles and supporting my son until he was able to ride on his own.

In the RESOURCE Phase my concern was to provide the supplies we needed such as buying the helmet and the boots and components of the first air kit for example to ensure that the day went well and we had all the supplies we needed.

(Figure 1)

I tried to layout the various components of the process using a diagram to show separation of these types of concerns.

Lesson 7: Process Components are Fractals and have their own threads

Interestingly, the task of purchasing a helmet from Target had its own model which involved preparations like fueling my car, getting a map, physically driving to Target, getting instructions for the location of the bicycle helmet aisle, selecting a helmet, checking out and paying for the helmet, driving back home and then parking the car. This sidebar model had ots own "locus" that touched upon the day's exercise of teaching my son how to ride.

The lesson was that the process pattern we established for the overall activity of teaching my son how to ride a bicycle was a fractal - its components displayed the same pattern in their own internal structure. In fact we can use the pattern as the DNA for any process.

I tried to depict the fact that each of the component activity phases had their own locus's using the picture shown below:

(Figure 2)

The secondary threads are not sidebars to the primary thread, but necessary processes required for the success of the primary thread.

Lesson 8 Process Components Deal with Different Variables

As we look at the various components (Phases) that make up the process pattern, we find that different variables are involved in each of these components as they address different concerns and measures related to those concerns.

(Figure 3)

Lesson 9: Modeling techniques are different for each of the components

Notice that the process component CONTROL is not linear but is always monitoring the progress of the other components to determine a course of action or to make decisions. The classic modeling technique for linear processing such as IDEF0 and BPMN do not work very well for modeling the locus of the CONTROL component. Rather modeling techniques such as OODA (Observe, Orient, Decide, Act) sometimes also called PDCA are more appropriate. In our story, when my son fell off the bike because he did not know how to get off, I had to redirect my training strategy and add an element of dismount training to make it all work.

On the other hand the RESOURCE Component needs lead time and a set of linear processes to provide the supply of resources at the right time to the right activity that is performing. In our story, I did not have the luxury to go out and earn the money I used to pay for the helmet at Target. I had to have cash on hand (or some other means of payment) to be able to walk out of the store, helmet in hand!

(Figure 4)

Conclusion

In my brief story are embedded many architecture lessons!  The DoD Architecture Framework is versatile enough for me to express the various concepts in architecture terms. However, the simplicity of the story in the beginning of this blog is lost in the various detailed renderings. An architecture description tries to represent with completeness and clarity all the various aspects of structure and behavior. The pattern that I have presented appears to be a powerful one for process modeling. The fact that each component can be recursively modeled using the same pattern is a powerful one because the pattern exhibits fractal properties.

I have always been intrigued both by the completeness and the simplicity of a IDEF0 Context Diagram both as a black box and as a fractal structure for decomposed activities. Flows and threads tend to make a model very complicated. At the same time flows and threads tend to be scenario and situation specific and their usefulness in enterprise modeling is about the same as Use Cases that are tailored snapshots.  Flows and threads also tend to "micro manage"  fine grain couplings that goes against the separation of concern approach expressed in this article.

 The current craze for using BPMN models belies the inherent simplicity of the Process Pattern as well as the separation of concerns that delegates the internals of a Process component to the performer.. Often we wind up with a spaghetti of carefully (and expensively) modeled BPMN flows and are struggling to place their context and define how they interlock.

Car Designer, Auto Mechanic, Car afficianado or Taxi Driver?

One very fine, very early spring morning I was driving to Union Station in Washington DC to drop off my guests who were taking an early train to New York. Living more than twenty miles away, we rarely go to Washington and even more rarely to Union Station. My daughter had taken the GPS and I was on my own with a few remembered landmarks, a tremendous faith in the city's road signs and confidence in my quickness of reaction from 45 years of driving. I had also given us plenty of time to fold in the allowance for mistakes and false turns.


As I headed down Interstate 66 and crossed the river, I made my first mistake. Instead of staying on Constitution Avenue which was the continuation of I-66 as US 50 I veered off to the right and wound up by the monuments headed towards Independence Avenue. Before I knew it I had veered off some more and found myself travelling into the tunnel and I-395 with the prospect of being marooned in Southeast DC and the dreaded Anacostia area with the housing projects.

The clock was ticking inexorably for the departure of my guests' train. I mumbled something about putting them in a taxi if we reached a point of no return in our journey towards Union Station by a certain cutoff. As we drove, my eye caught the AMTRAK symbol sitting below the Massachusetts Avenue exit. To change three lanes and take the exit was the work of a moment.

As I grimly followed signs to Union Station, I was able to hang in there and get to the station with a little more than an hour to spare for the train to depart. Two happy guests bid goodbye and went off to take their train.

What does this story have to do with enterprise architecture?

Knowing how to operate the car was the least of my problems. Whether I was driving my own car, or my wife's or my daughter's, I was equally comfortable. The problem was the ability to plan, correct, navigate, constantly redirect and correct, recover from mistakes, and interpret and use information to make decisions. A combination of all of these were required for me to reach Union Station.

In the EA and architecting industry we hire people for the cars they know how to drive! Today, most architecting organizations hire people because they have Provision knowledge or System Architect Knowledge or Troux or Mega or.. They know how to operate the car. But do they know, during the course of a architecture project, how to plan, correct, navigate, constantly redirect and correct, recover from mistakes, and interpret and use information to make decisions?

We also hire System Engineering experts and practitioners to help us drive to Union Station.

Systems Engineering is the process of building the car and is even more removed from driving or operating the car. Systems Engineers should be working at General Motors and not as taxicab drivers. In the US, we appear to be using System engineers to also help get the enterprise "to Union Station and then on to New York". When we hire for knowledge of System Architect 11.0, we are hiring drivers very knowledgeable in operating a Ford Taurus 2012 Model to help us get across a town that is strange to them. We need to rethink the skills for architects. And we wonder why enterprise architecture projects are not successful or any different from systems engineering!

An experienced driver with knowledge of many roads and cities but also with the agility to "observe, orient, decide and act (OODA)" is a tremendous asset to an enterprise!

Ops Tempo? What's That?

Hummingbird

The Importance of Recognizing Operations Tempo


In the field of Biology, we see an interesting phenomenon - small animals tend to have a high rate of heartbeat and pulse and live shorter lives, carry their young for shorter intervals inside their bodies and tend to also have a high rate of activity. The hummingbird is a classic example of such a small animal as is a nocturnal creature - the bat.

In the battlefield, we use the word operations tempo to describe the rate at which a battle is fought. Increase the ops tempo and you tend to burn more ammunition, fuel and lose more people. Decrease the operations tempo and you tend to have protracted warfare that allows the enemy to reform, regroup and fight more resolutely. The commander's challenge is to operate at the highest operations tempo possible that a supply chain can sustain (of course ensuring that he has technological superiority and can deliver a convincing blow with the increased operations tempo).

Enterprises have their own operations tempo, partly driven by the nature of their business and partly by the need to compete and match or better a competitor's rate of operations. For the enterprise architect, it is very important to understand the operations tempo of the enterprise she is analyzing.

For the simplistic analyst, who believes that government should operate as a private corporation, is to deny the mismatch between the operations tempo in the government and that in a private corporation. For the government person to believe that their experience in Government qualifies them to lead a fast paced private corporation is also equally simplistic.

Governments have for the most part, been in business for decades if not centuries. They have evolved gradually, increasing their operations tempo with infusions of technology, turnover in personnel and adoption of new laws, policies, rules and regulations. Governments are constrained by legislatures to pay modest wages with little incentives to improve performance.

Private corporations on the other hand are nimble and fleet footed and is able to sustain a very high operations tempo based on providing windfall rewards and rapid rises in positions for their employees. They are able to form their own specific organization structures, supply chains, policies, procedures, processes that are geared towards this high operations tempo. Even within private corporations, there is a diversity of operations tempos. Older, established long lived corporations tend to behave like the Government, while startups that are pre-public offering work at a frenetic operations tempo that is seldom sustainable after they go public.

The classic mismatch is when a person leaves a slow ops tempo enterprise to lead a fast one or when a person leaves a fast paced private enterprise to lead a slow government enterprise. Experience has shown that the transition from one enterprise with a dramatically different operations tempo than another is challenging and few people successfully make it successfully.

Another form of classic mismatch is when two organizations need to collaborate or form different parts of the same value chain. A lot of frustration results when the operations tempos of the two organizations are dramatically different.

Away from enterprise architecture land, in the people world, we tend to categorize people as Type A or Type B personalities. Unconsciously or consciously we are also assigning a value of operations tempo - Type As tends to work at a high rate of operations tempo while Type B's are slower in their operations tempo. Dating, marriages between mixed types or similar types are examples of operations tempo mismatch or match with interesting consequences. Entire families may have a distinct operations tempo and interactions of family members with other family members may be fraught with frustration.
Ignore understanding and factoring in ops tempo as an enterprise architect at your own peril!

Emergence

In an earlier post I was complaining about the Washington Area traffic. The nation's capital is also the site of capital traffic jams. Highways are shut down due to construction or all but one lane is blocked off and a long line of cars are burning gas and waiting patiently to get through. Very quickly like water pressure finds the weak point in a submarine's hull, the traffic finds an exit to some side road that runs through a quiet residential neighborhood. Soon all the cars are pouring through roads that are single lane wide and riddled with stop signs and a 25 mile an hour limit.


The careful well planned highway capable of carrying six lanes of traffic at 60 miles or more an hour lies idle as the side roads are choked with traffic far beyond their carrying capacity. What is happening here? The drivers are exhibiting emergent behavior. If one were to magically wave a wand and expand the by lanes to turn them into highways, they would soon become the "new normal" until the old highway comes back into service. Maybe the old highway may never be used again.

I am a fan of the late author Michael Crichton. Only now as I am slowly beginning to understand emergent phenomena, I am beginning to realize that emergent behaviors are a thread that run through most of his books - be it a virus mutation in the Andromeda Strain, the adaptive learning of the human brain in The Terminal Man or the emergent behavior of prehistoric animals brought back to life in Jurassic Park.

I look at nature and I see emergence everywhere. The termite hill in the distance is a product of emergent building as are ant hills, bee hives, and bird's nests. Did they have a static plan when the insects and animals who built them started? Or did the hill or hive or nest get built as they went along? Did the icicle always grow at the same place (crystalline structures are fractal, but the overall shape of the crystal may be a result of lopsided growth).

Emergent behavior, speaking loosely is an unplanned evolution of behavior that results from many factors, often unanticipated. Emergent behavior defeats the static planning and the estimation of dynamic calculations that form the bedrock of architecture work. We as architects are trying to plan the various parameters of a system based on assumptions of growth and evolution and capacity limits and topological structures that reflect the world as we understand it today and our assumptions for the next say, three, five or even ten years. Emergent behaviors tend to wreak havoc on this planned and organized way of being. Emergent behaviors are opportunistic. Emergent behaviors are driven by unforeseen constraints, an urge to get ahead, impatience with the static status quo and a host of other motivating factors.

Emergent behaviors seem to exacerbate when there is an explicit disconnect between the "swarm" and the resources. I had observed behavioral differences between customers at fast food restaurants in Germany where you have to ask and pay for ketchup and jam versus customers in the United States, where these condiments are set out in piles of packets for customers to help themselves.

I am looking forward to doing more research on "emergent architectures" and the phenomenon of emergence as it relates to systems engineering to develop ways to manage the evolution of architecture topologies to match emergent behaviors rather than stay static with the assumptions of yesterday ill suited to the behaviors of today. The area of cloud computing is a domain that is akin to the fast food example I have mentioned earlier.