Do Your Own Kata

Several years ago I had the privlege of stuyding Okinawan Goju-ryu Karate with a local sensei. With little to no interest in physical activity I found this to be a great way to get some exercise for both my body and mind.

While learning katas – or series of movements – we would practice them as a group. Quickly sensei would realize those who knew the katas and those who did not. The ones always looking around at another student were the ones who may not have studied the kata sufficiently. It resulted in a klumsy attempt at executing the moves. Possibly, the moves looked worse than the student individually moving through the kata even with an incorrect move or not.

The advise from sensei was always to “do your own kata”. Sure there would be outright mistakes or small opportunities for improvement. In fact, there are always opportunities for improvement. One can spend a lifetime perfecting the simplest of katas. I’m reminded of the very isometric Sanchin kata which is the first kata I learned. Each and every belt test – after we were completely exhausted – we would always go back and perform this kata.

There are some takeaways from this portion of my karate experience:

  • Preparation. In order to be proficient in our tasks as professionals or other roles we play in life (e.g., spouse, parent) we need to do the homework. We need to nourish our minds and bodies with the right intellectual nutrients in order to perform at our best. Doing the homework builds our confidence and ability to perform with intentionality and precision despite nuanced flaws which may appear. And may appear only to ourselves 🙂
  • Focus and Self-reliance. After doing the homework we need to be able to execute independently without “cheating off of someone else’s paper”. When we perform in a group or team setting our contributions do need to mesh with others. But like in the dojo (e.g., belt testing) there will come a time where we need to perform on our own such as an public presentation or interview. This is where we “do our own kata”.

Pivoting a bit within the martial arts, I’ve recently tried a few Tai Chi classes. While considered a martial art, its much more like moving meditation than karate. The movements are still derived from self-defence and offensive moves. However, the movements are slowed dramatically which helps build muscle and mental strength. All my Tai Chi practice to date has been in a group setting. It is rewarding to see several of us with varying ages and health execute the moves in unison.

There are times where we must perform on our own. And times we must contribute to a larger chorus of movement. In either case, preparation, focus, and self-reliance all play an important role in the final outcome.

twitterlinkedinmailby feather

Life = Dojo

I studied (Okinawan Goju-Ryu) Karate not too long ago. It was perhaps the only athletic activity I every really enjoyed in my life. I because a karateka (student) in my mid-fourties. I studied at the local YMCA where my shihan held class for beginners. Beginners were age 5-n where n is something closer to my age. I was the ONLY adult in a class of pint-sized kids. Fortunately, my sensei grabbed a few other adults to work with me so they could assist their kids. Soon I befriended a few other karateka in my “demographic” while I continued to train.

Kramer in the Dojo

One interesting lesson I took away – and there are many I should harvest – is about the relationship between the teacher and the student. While its obvious to most folks the karateka with the black belts and extra markings are teaching. But what happens in the dojo is interesting as I’ve relied on younger (as in my kids’ age) karateka to guide me through a kata or other basic technique (kihon). Everyone is a student, and everyone eventually becomes a teacher if they stick with it long enough. No one advances into the senior belts and eventually the black belt until they are leading classes and helping less experienced karateka.

There is a sense of humility and emptiness one needs to experience in order to harvest the benefits of a younger teacher. There may be a teenage black belt in the dojo who I am expected to address as “sir”. The dojo knows no ages as all are shown respect. This notion quickly revises the essence of diversity training I’ve received during my career. We are taught to look beyond apparent differentiators in our lives to collaborate and cooperate in an enterprise. Such is no different and reinforcing within the dojo.

Some may consider me rather old. Others may consider me still a kid. But with my current consulting assignment I’m blessed to see a large number of individuals who are so very different from me. One gentlemen (who I want to call “kid”) is considered an expert on our team with a particular technology. Others are from a variety of countries and backgrounds which makes for some FINE dining when we get together. More importantly, we are collaborating and learning from each other. We cannot let title, age, or other differentiators block us from the opportunity to learn and grow from other individuals.  Otherwise, we simply poison ourselves and stunt our own personal growth.

twitterlinkedinmailby feather

Law of Navigation

Reposted for the holiday season. I’m just about finished with Maxwell’s book so I feel less guilty :).

It may not be fair to blog about someone’s book without reading the whole thing. In fact, I didn’t even have the decency to review the first chapter or so. Courtesy of Business Book Reviews, I took an early peek, through the reviewers pen, of John Maxwell’s The 21 Irrefutable Laws of Leadership. What stood out is his Law of Navigation and how it relates to Enterprise Architecture (EA).


What struck me was the example given about two South Pole expeditions in 1911. In short, Scott’s team perished due to a lack of vision and planning. Amundsen’s team did not because of the exact opposite.

While traversing my career I’ve often thought I spent too much time worrying about a particular technology or even design pattern to apply to a solution. In my most recent years it is apparent that while all the designy stuff is important, the leadership “chops” the EA brings to the table is arguably more important. The EAs are charged with seeing beyond the current week or month and (should) have the firm’s strategic objectives in mind rather than the next milestone on the project. I’ve shared with clients my boss talks more about leadership than any other topic within our EA consulting practice. Leadership is one of the DNA strands of this thing we call EA.

We have plenty of folks incentivized in firms to think tactically and achieve short-term objectives with minimal regard for the long term. EAs are charged with fighting entropy and viewing things from a longer range perspective. One should not confuse “fluffy” or “pie-in-the-sky” with visionary action that can provide sustainability to a firm. This visionary DNA can afford organizations the competitive edge required to survive in a hostile competitive environment.

twitterlinkedinmailby feather

The Earnings Call Litmus Test

I recall a story – with questionable accuracy and no citations – of a NASA janitor during the Apollo era who was once asked what he was doing as he swept the floor of one of the offices. He replied, “I’m putting a man on the moon”. This man understood the connected nature of his job and how it created the mental space for others – along with him – to contribute to an amazing engineering feat. [Considering the total computing power in the world was less than an iPhone 4 makes this near miraculous]

Wind forward to present day. The nature of my job compels and requires me to draw connections between “things” in organizations. They range from business capabilities, processes, and KPIs to software and hardware components. Organizations evolve these “things” which I typically refer to as elements through programs, projects, and eventually, that action item you raised your hand about at the last meeting.

So regarding the aforementioned pile of action items: what captures our energy from day to day? Are they the relevant things? Is what you are doing right now contributing to the progress of your overall task assignment or project? Is it cruft that doesn’t add value? Are you applying the relevant amount of energy to this task? Can you connect your work to something relevant to the next earnings announcement, annual report, or publicly stated objectives?

If the answer is no, then now is the time to take action to link it to a relevant task/project/program. This linkage may not be direct as in the case of the NASA janitor. There may be several layers of indirection between “plant maintenance” and “liftoff”, but in the case of this NASA janitor he understood the connection.

If what we are working on is not linkable, they eliminate it. My thoughts on this topic are inspired by a few individuals:

  • Greg McKeown, in his book Essentialism, encourages us to eliminate the unnecessary. We can accomplish more by doing less. Being busy does not equate to effectiveness. We shouldn’t be efficient and wasteful tasks.
  • The wild and crazy 🙂 Tim Ferriss, author of The Four Hour Body, talks about the “minimum effective dose” (MED) to apply to a wide range of topics. Water isn’t “more boiled” at 213F. Only apply the minimal amount of effort.
  • Larry Wall, creator of the PERL programming language, extols the virtues of a good programmer. The first of which is laziness. My interpretation is that less code is better than more code. Why? Because there is less to maintain and break over time. Sometimes the term “gold plating” is used to describe this desire to over engineer a solution. Less is more.

Link or eliminate. Focus on what is relevant.

twitterlinkedinmailby feather

Next Generation of EAs

Recently I was asked by Oracle’s architecture community manager about the next generation of EAs. The topic was centered around where future architects should focus their energy. Since the original article can only share a small snipet of my thoughts I’ve added the remainder below.

The next generation of EA would do well to spend as much, if not more time, consuming business literature and emphasizing the business planning aspect of EA. As I convey this idea to clients in IT departments, I emphasize the result of a rigorous EA development cycle – a roadmap to evolve the business. Its not a functioning piece of technology. Its a roadmap. Level 0 project plan by any other name. When performed correctly, the roadmap is executable from the sense of funding and creating a stream of projects. Current EAs who are leveraging EA and not only EAA, EIA, or ETA understand the need to emphasize and orient around the business elements of the enterprise. Nearly half of TOGAF’s “elements” that are inventoried and modeled are out of the business domain.

I think EAs will start harnessing other skill sets and weaving their respective tools into an architecture development process (ADP). Service design, design thinking, and Lean Six Sigma are all tools for evolving an enterprise’s capabilities. One question that arises is whether or not EA is the right name. Are we “enterprise transformation-ologists” (or some other name) that leverage the tools of enterprise architecture and/or the aforementioned list when tackling a planning cycle or specific problem?

Regardless of the answer, the basics of problem solving and business fundamentals will always be relevant so all species of “architect” will benefit from immersion into those domains.

twitterlinkedinmailby feather

My Experience with Mindfulness/Meditation

A number of journals and articles in recent months are addressing the ancient practice of meditation or mindfulness. I suppose those more engaged with this practice would distinguish between the two. The following is less a technical discussion of the topic but rather my random thoughts based on my experience. Two ways I find some benefit from mindfulness/meditation:

  • Clarity. I was first introduced to the idea formally during a leadership training course at a prior employer. For whatever reason the simple 5 minute exercise seemed to resonate with me right away. The idea of clearing my mind (or rebooting for my technical friends) prior to engaging in a training session made perfect sense. I found it very easy – and still do – to let my mind drift into a hundred directions during a meeting or training class. This reality has nothing to do with the quality of the instruction or relevance of the topic. It has to do with my mind wanting to float and drift to any shiny mental object crossing its path. Add to this our 21st century gizmo-enabled-always-connected (GEAC) world and the challenge of mindfulness is only amplified.
  • Buffering. Another area I find benefit is with building mental space – building the gap between the multiple stimuli in my life and the reaction or response. The stress of everyday life could wear on us to the point we have no more fuse and thus an immediate and negative reaction may ensue. For me this practice builds a buffer or level of indirection. Early mindfulness sessions taught me to simply recognize what is going on in my head and catalog it. Recognize the emotion whether positive or negative and address it at the right time. I understand categorizing the emotion positive or negative is generally not advocated by the mindfulness community. But sometimes it is just obvious.

Back to definitions: my take is mindfulness is something practiced continually throughout the day for any task we might do regardless of its importance or triviality. Something as simple as packing my suitcase for a trip can be a mindful activity. If I pay attention to the things I put in the bag, then I don’t stress out on the way to the airport wondering if I forgot a critical item difficult to replace. Conversely, meditation is the gymnasium or dojo for building these muscles. It is not for just the stressful moments but rather for those calm portions of our life. We “store up” the mental strength and self-control needed to deal with life.

What about you? Are you engaging in the practice of meditation/mindfulness and if so what benefits are you observing in your journey?

twitterlinkedinmailby feather

On Women in Computing

Its 2014. Why are we still debating about equal pay for women in the workplace? And specifically in IT-related fields? It is downright ironic if you ask me given the contributions of the following two women in the profession:

  • Ada Lovelace from the 19th century who worked on Babbage’s early “computer”. Eventually, a programming language, and one of my former student interns, was named after her.
  • Rear Admiral Grace Hopper is known for her significant contributions to the development of the COBOL programming language but also for popularizing higher-level programming languages (versus chip-specific assembly language). And while many might lament the zillions of lines of COBOL still being maintained around the world the fact remains it was a huge contribution to the world of business computing. And that s— still runs!

So why are we still struggling with this idea of equal pay? If we are truly adopting outcome-driven, results-only work environments then why the disparity in the compensation? Is there a link and stigma still around women who take time off for maternity leave, doctor’s appointments, and other family duties? Perhaps this “time off” is being viewed as not working “hard” when really – consistent with ROWE – is we should focus on working smarter while still delivering on commitments.

I recall a professor I worked with who was responsible for recruiting students into 20-week work assignments required for their undergraduate degrees. His management continued to pressure him for more women to apply and eventually be hired. On my side it was rare I would turn down any candidate – But the professor exclaimed to his management that women were not applying because they simply did not exist! Of the 20–25 students I hired, only two women ever applied and were subsequently hired on their qualifications.

Which forces me to look inward. What barriers exist that need to be eliminated? In the workplace? In me? What are your thoughts?

twitterlinkedinmailby feather

On Complexity

I’m not convinced all complexity is bad. There are complex elements in our lives that enrich us. I’m reminded of the first few times I tasted Thai or Indian cuisine when my mouth was alive with a myriad of flavors coming from multiple directions. Just the curry alone consists of eleven different spices hand-tuned to the right mix of savory flavors when prepared by authentic cooks. Which is in contrast to the curry-in-a-spice-shaker I use. Or consider the complexity of some red wines or whiskeys. Many flavors emerge such as tobacco, leather, berries, or chocolate. In the case of these foods, we enjoy the complexity. Its like a crossword or other puzzle for our minds.

But the business word is rather different. Publicly businesses have a 90-day circadian rhythm of KPIs they are held to by their customers and Wall Street. There are efficiencies that must be realized in order to achieve certain objectives. However, as companies grow and introduce new products and services to the market new complexities arise. Per-product processes and supporting technologies are introduced which can bring along duplication and thus confusion within the organization. Couple this phenomenon with the realities of merger & acquisition (M&A) activity which also can introduce duplication into the enterprise. In the [death] march towards regulatory compliance, new customer acquisition, and frenzied product/service launches its easy to introduce some unneeded complexity and assert “we’ll go back and fix it later”. [Insert “head exploding” emoticon here]

This is the unneeded complexity in an organization and should be excised from organizations. Otherwise, it saps the innovative energy which could be devoted to driving its value propositions forward. It is possible that the introduction of unnecessary complexity creates a brittle and unresponsive core to the business. At this point budgets are simply consumed by “business as usual” operations coupled with minimal compliance measures. Forget about innovation in these environments.

I recall reading about “unnecessary complexity” in Frederick Brooks’ The Mythical Man Month. The qualifier “unnecessary” suggests there is some necessary complexity inherent to enterprises and other systems within our world. I believe Grady Booch touches on this topic in one of his works. Those charged with modeling and subsequently designing new capabilities within these organizations have a responsibility to recognize and manage this complexity while at the same time optimizing it by removing unnecessary elements. In some cases there are elements and combinations of elements which appear complex even when optimized. The designer then has a responsibility to convey and reflect this necessary complexity in a layered, intelligent manner. This allows different types of stakeholders to understand the complexity in incremental steps. This is in contrast to an approach where one creates an A0-sized depiction which only causes headaches and eyestrain for those of us older than 40.

I’m not convinced that all complexity is bad. Eliminating necessary and managing necessary complexity becomes the task of the business designer – or all individuals – within an enterprise.

What are your thoughts on this idea? Is all complexity bad? How do you manage complexity in your work? I invite you to share your thoughts in the comments.

twitterlinkedinmailby feather

Why Metamodels Matter

In the process of evolving a business the question of scope arises in my mind often. If I don’t have a boundary to work within, I can get distracted and the project can go sideways. With business design projects that leverage enterprise architecture (EA) the frameworks often supply a metamodel. I believe it is a key item in scoping and organizing the work.

The metamodel is the model about the model. Said differently, it is the structure I use to categorize and relate the various elements being cataloged and eventually. Capturing the metamodel can take many forms including UML, plain text documents, or more rigorous ontologies leveraging languages like OWL. Regardless of approach this task is less of a technical task and more of an ontological task. Yes, call in the philosophy majors.

Some considerations regarding enterprise metamodels include:

  • Establishing common vocabulary. Like common framework, the metamodel can establish common vocabulary for working within the enterprise. If an organization can establish this common vocabulary one can facilitate more rapid discussions across departments and lines of business to identify areas for process improvement and consolidation.
  • Defining Scope. What do we really care about and how does it all relate? During my initial framework training years ago, John Zachman contended businesses (and I think government agencies) are much more complex than an aircraft. If we are to “understand and then be understood” regarding a business’ capabilities evolution, we need to have this information cataloged in a tidy-enough way to facilitate planning.
  • Aiding Interoperability. We see organizations buy and divest themselves over their lifespan. HP recently announced a split between their consumer and enterprise products & services. I’ve seen retailers buy and then divest their purchases within a 5–7 year period. Having the organization’s elements defined explicitly – even if different – allows the M&A conversation to accelerate. It facilitates identification of common business elements and mapping of differently named items. I would posit an early conversation on M&A activity should include conversations between the respective organization’s enterprise architects to see how their own metamodels align and then begin identification of common capabilities.
  • Metamodels are not for stakeholders. Regardless of the metamodel you are leveraging (e.g., Zachman, TOGAF), keep the hairy details yourself. Stakeholders, especially those who are not IT, will not care a bit about the metamodel or the gory details of the semantic relationships between the elements. Since it is part of the EA framework, practitioners should keep it hidden and convey the information in an audience specific manner.
  • Metamodel definition is organization-specific. Organizations like The Open Group and The Business Architecture Guild define metamodel for use in enterprise modeling. Users of these models should tailor their models to reflect the needs of their organizations. But only to do so to accelerate learning and evolution of business capabilities. One ontology I’m not willing to suggest tailoring is Zachman’s as he covers the size base interrogatives contained in several modern spoken languages. Yes, I’m afraid of that little pointer he uses during presentations 🙂

How is your organization leveraging this portion of an EA framework for evolving a business? Do you explicitly define your organizations metamodel and consistently model the elements? Do you rely on a formal tool? Please let me know in the comments.

twitterlinkedinmailby feather

Moore’s Law Deemed Hazardous

The advent of digital computers has brought a seemingly unending supply of innovations. Broadband communication to our homes and portable computers ranging from laptops to pocket-sized computers (aka, smartphones) make working anywhere 24/7 viable. This innovation also makes petabytes worth of cat videos available to most of the planet, but that is a topic for another post.

This abundance of computing power is creating slop. Slop in the process and slop in the code. Why? Because a compile and test cycle costs us nothing more than a few keyboard strokes. Most of us wouldn’t have time to sip a Mt. Dew in the time it takes to build the code and run the test cases.

Our desktop computing capacity far exceeds that of the mainframes of yesteryear. A machine with 8–16GB of RAM along with tons of storage is standard fare and easily fits into a briefcase or backpack. I mean, why the hell would you even bother checking the code? Yes, I mean a walk-through either paired-programming style or actually printing it and getting a second set of eyes. This rush to deliver business functionality seems to be fueled by Moore’s law. Computers run faster leads to more requirements demand which leads to creating faster computers. It is a vicious cycle unless you are in the cycle making money along the way.

Back in the days of white shirts, black ties, and pocket protectors a guy named Frederick Brooks was a project manager for the S/360 project at IBM. For those of you wearing skinny jeans, the S/360 operating system is the foundation for what still runs on zSeries mainframes today. In his book The Mythical Man Month, which I strongly recommend you read, Brooks describes the cultural environment and requirements for developing software in the 1960s. There was no quick keystroke to compile your code. You walked down the hall and presented your card deck like an ancient Jewish sacrifice to the computer room for processing. But only on your assigned compile day. Maybe if you were lucky the code came back clean in time to run the tests the in next day or two. Yes, the cycles were measured in days. In those days they had to spend time checking the code they hand wrote before submitting the compile job. Even in ~1985 I was required to write out the code and produce a flowchart – with one of those IBM stencils – before heading into the lab in college.

But this rant isn’t just about the code. It’s about the process. I’ve seen the evolution from waterfall step-wise deliver to more iterative RUP-inspired approaches. I’ve also seen what is termed agile. But I increasingly think the term “agile” is a moniker being applied to those who are just coding-and-going with no sense of discipline until the code breaks in production. Where did we lose our way? Maybe I haven’t met the folks who are really leveraging agile to delivery mass amounts of quality code to drive successful businesses. I’m not advocating for waterfall, but is there a balance to be struck between a process straightjacket and process anarchy?

There was a sense of precision and care that was necessary due to the restriction of computing power. I haven’t worked in industries developing safety-critical software-intensive systems like a Boeing, Airbus, or Lockheed Martin. I imagine (pray?) this level of discipline still exists in those industries regardless of computing power. But could we benefit from a good dose of Dr. Brooks’ world when approaching the design and development of software-based solutions?

And yes, you can get off my lawn now.

twitterlinkedinmailby feather

© 2016 Eric Stephens

Theme by Anders NorénUp ↑