Sunday, December 15, 2013

You Cannot Move Too Fast

This is the time of year when I seem to notice the speed at which other drivers on the road are traveling, and when I say "speed" what I mean is the plodding, lethargic, and dawdling forward movement of my roadway cohabitants. What is it that causes drivers to suddenly assume that speed limits are upper-end suggestions, and not the result of engineering to balance safety and throughput?

I'm not talking about inclimate weather, or massive traffic snarls; no I'm referring to that guy who is burning down a two-lane road at the rate of: ((Speed Limit) - 11). As if that weren't enough, I actually had the opportunity to trail a backhoe that achieved 10 MPH. I was tempted to horn him, except he had that giant claw on the back of his vehicle which could have chewed my Grand Cherokee to bits. Live to fight another day, I always say.

In another blog posting a few months back I discussed my conversation with George Coloney, CEO of Forrester Research and our take on the five elements of Digital Disruption. One of the five was that you can't move too fast. In this day, if you have an idea to generate revenue, streamline operations, or reduce costs, complexity, or obstacles - you cannot move too fast in implementing your plans.

Consider - the world’s information is doubling every two years. More video is uploaded to YouTube in 60 days, than the 3 major TV networks in the US have created in the last 60 years. In 2011 the world created a staggering 1.8 zettabytes of information. By 2020 the world will generate 50 times that amount and 75 times the number of "information containers". Competitors are literally springing up from nowhere, and even the ones we know about are moving at unprecedented speed.

You cannot move too fast.

This is not a license to be stupid, or to move without thinking, rather it is an acknowledgement that self-restraint is not an advantage when attracting new markets, business, efficiencies, or customers. Surely, one must have principles and governance relative to quality, integrity, and judgement, but the notion that we must take our time is dead. Metaphorically, when the light turns green, for Pete's sake - GO!

So, if you have an idea to improve your business, you must execute NOW. Not in six months, not in a year, and not when things settle down. Yes, be smart, plan your steps - but move it forward today!

Wednesday, October 30, 2013

Beware Architecture Ghosts that go BOO!

As the Cowardly Lion once remarked, “I do believe in ghosts, I do, I do, I do believe in ghosts!” In the technology space, ghosts are fateful decisions, implicit or explicit, that are buried within a solution until the right set of circumstances raise them from the dead.

For instance, in January 1990, AT&T experienced a cascade of failures in their long distance network switches. It seems that each switch is capable of shutting itself down upon receipt of a special message. This, in and of itself isn’t entirely bad - there may be instances where you would want to shut down a switch. Unfortunately the “special message” is routinely initiated by a switch when it is itself recovering from a failure.

So, a system fails for some reason, and is brought back online whereupon it signals to its neighbors that it just recovered from a failure and sends the “special message.” Each neighbor in turn, crashes. Upon recovery - they each send out the same special message, and so on, and so on.

No one designed this in a deliberate sort of way, however the architecture was likely discussed, possibly debated, and … at … some … point … decided, i.e. thinking died. Thus a ghost was introduced into the system to remain forever dormant until that one special day.

Architecture ghosts are real, they even have names. We call them Sev-One and Sev-Two. These ethereal entities are the antithesis of reliability, availability, and predictability. Architecture ghosts are usually the result of tight coupling, but can be created out of two insidious verbal incarnations that include the demonic phrases of “there’s not enough time” and its evil corollary “that will never happen.” Speak these at your own peril.

As our thoughts turn to pumpkins, candy, and things that go beep in the night - let us learn from the architecture ghosts of our past. When Sev-One or -Two jump out to say Boo, let’s do a little Ghost Busting, and fix the real issue.

Monday, October 21, 2013

Best of Breed or Best of Suite?

Image if you could plan your next vacation by taking your favorite beach, with your favorite amusement park, your favorite restaurant, favorite mini-golf, favorite ski slope, bowling alley, go-cart race track, hotel suite, and of course cruise line.

For instance, if I could somehow combine the travel time of Delaware Beach, with Typhoon Lagoon, Alaska's Aurora Borealis, the Grand Canyon, Las Vegas Strip, and my home entertainment system, I'd be all set for a fabulous vacation.

What my wife and I end up doing is rotating across and between our favorite vacation spots, accepting the fact that on any given year we're sacrificing one perfect experience for another.

Arrrrrrrggggghhhhhhh... I never seem to get away from Architecture Decisions!!

Do you favor Best of Breed solutions, or best of suite? My dad has never bought a computer from Dell, HP, Gateway or any other name brand vendor. He buys power supplies from one guy, motherboards from a website, hard drives from the manufacturer, and so on. He says he gets the best components that way and can build the best system.

Me? I'm a Best of Suite guy. I like getting a packaged solution, at a fair price, where I have the expectation (and legal leverage to demand) that all of the pieces work together. Given a choice between buying the components of a great PC (like Dad), or just buying a Dell (or Gateway, etc..) with Windows, Internet Explorer (which I will use exactly one time - to download Chrome), and Microsoft Office - well, given the choice, I'll take the packaged deal.

This has become a lot more interesting with the advent of TeraData, Exadata, Exalogic, and their Ilk. I remember introducing the Google Search Appliance in my company years ago and how that changed the way we addressed intranet searching.

These solutions combine hardware, operating systems, and some software solutions, all tuned to work together. You do lose some ability to customize the various components, and you are at the mercy of a single vendor if something goes wrong. Then again, being at the mercy of a single vendor is sometimes preferable to being caught between two or three adversarial vendors each claiming the other is at fault.

So which do you prefer; Best of Breed, or Best of Suite?

Monday, October 14, 2013

How many Architecture Committees do you Need?

Most of us look upon committees with the same level of anticipation and admiration as a dental exam. We accept that they are necessary, but could easily do with out the picking, flossing, or emotional preparation.

We've recently undergone a significant reorganization as a result of hiring a new CxO into the organization to lead our technology and operations functions. With new leadership came a new decisioning matrix, a.k.a. committees structure.

I've been actively engaged in architecture governance for over ten years in my company, and have had the opportunity to see how a number of other profit-centric corporations handle this question. There needs to be at least two levels of governance, but the actual number of committees can vary greatly depending on size, velocity, geographic distribution, disparity of business function, and diversity of technologies.

Well run committees are great places to bring visibility to a topic, to remove personal preference and bias, and to inject predictability into an organization's decision-making process. As such, there are two fundamental questions that architecture committees should be asking and answering:

  • What should we do?
  • How should we do it?

The first question is sometimes changed to "Should we do this?", but the key operative is still, "Should." This question is about business aspirations, policy, principle, and sometimes cost and timing. The members of this committee must be leaders of the technology and business teams and have accountability for directing resources such that once the "Should we" question is answered with a "Yes" there is no debate among the worker-bees as to the direction.

The second question, "How.." assumes that we are going to do the thing in question, and the task is to accomplish it within (or as close to) the enterprise standards. Exceptions are always possible, with proper vetting and visibility.

Some have asked, doesn't the "how" sometimes affect the "should?" No! It.Should.Never.

I cannot think of a business need or requirement that would garner a "Yes" vote on the question of "Should we" and then be cancelled or rejected because it's just too hard. The obvious exception to this rule occurs when the business community says "We want product X" rather than "We need function X." Businesses should never dictate the "How" of a solution, only the "What." If you avoid that conundrum, you'll never find a "Should we" that contradicts with a "How do we."

So how many committees do you need to effectively manage your architecture decisions. Without a doubt, larger organizations might require more simply as a workload management vehicle, but that aside, you'll need the two functions mentioned above - which may be spread across a small number of committees.

We ended up with an Executive Standards Committee, two subcommittees (one for applications, one for infrastructure) and a series of architecture working groups. There is some overlap in memberships to ensure consistency, but not so much that it would inhibit challenges. The executive and subcommittees address the "Should we", while the working groups focus on the "How."

What do you have?

Monday, October 7, 2013

You want my what?

The scene opens with our Mild-Mannered Enterprise Architect (MMEA) using an online store to rent some photography equipment. It seems our MMEA fancies himself as an unpaid professional photographer and has been pressed into a photo shoot for a good friend. He needs a special, very expensive, camera lens that is available to rent from a company with whom he has done business in the past.

The MMEA has selected the lens he needs from the online store and indicated that he wants to rent it. Rather than being directed to the “Check out” page the MMEA finds himself being asked to call the store to complete this transaction.

The MMEA makes the call, but is wondering why the store isn’t calling him...

Camera Store Agent (CSA): This is Cameras R Us where we put our customers first, how can I help you?
MMEA: Yes, I’m trying to rent a lens off your web site, and it says I have to call.

CSA: Oh, yes, that happens when you are trying to rent one of our expensive lenses. Which one did you need?
MMEA: I need your part number VEL-1094.

CSA: That is a very expensive lens.
MMEA: Yes I think we have established that, that’s why I’m talking to you, you know, to rent one for the weekend.

CSA: No problem, we just need your credit card and a few additional pieces of information.
MMEA: Oh, like what?

CSA: We need a photocopy of your driver’s license, your social security number, and a utility bill.
MMEA: {chuckling} That’s funny. No seriously, what do you need?

CSA: A photocopy of your driver’s license, your social security number, and a utility bill.
MMEA: Why would you possibly need a utility bill? If I fail to return the lens, are you going to shut off my gas?

CSA: It helps to confirm your address. We ask for these things to protect you. We put our customers first.
MMEA: To protect me?

CSA: Yes, someone could have stolen your credit card, but it is unlikely that they also have your driver’s license, social security number, and a utility bill.
MMEA: What’s unlikely is that anybody gives you this stuff.

CSA: Actually, on any given day we have about a dozen rentals out like this.
MMEA: So just to be clear, on any given day you collect a dozen drivers licenses, social security numbers, and utility bills?

CSA: Yeah, for your protection. We put our customers first.
MMEA: Do you delete them when the lenses are returned?

CSA: Well; if you ask, but we like to hold on to them to make your next rental more convenient. As I said…
IN UNISON: We put our customers first.
MMEA: So, where on the site would a person upload this stuff - I’d like to see the security.

CSA: It’s actually easier than that, you just FAX it to us. Our customers find it more convenient.
MMEA: FAX? as in phone number, dial tone, and paper lying on the floor? Have you heard of identity theft?

CSA: Sure, but what’s that got to do…
MMEA: ‘Cause with that information you could pretty much become me. I’m not sure my wife would know the difference.

CSA: We’d never let that happen, you know we put our customers first.
MMEA: Yeah, I got that. What if we traded? Would you be willing to give me your driver’s license, social security number, and I’ll let you skip the utility bill.

CSA: Clearly sir you are not interested in doing business today.
MMEA: My point exactly, could you pass this along to your management?

The MMEA did the photo shoot without the very expensive lens, but with his identity intact.

Tuesday, October 1, 2013

Everything I know about Enterprise Architecture I learned from Charlie's Angels

Some things naturally come in groups of three; primary colors, broadcast television channels, and Charlie’s Angels to name a few. A case could be made that there were five Angels, one of which was a sister of another, so maybe that makes four and a half. Possibly I know too much about bad ‘70s television - no doubt because there were only three channels.

Enterprise Architecture comes in three flavors; Business, Information, and Technology. Business is like the attractive, smart Angel. It all about capability and forward thinking. Business Architects are really challenged to ensure that the other Angels, er Architects, are aligned and able to deliver the value that Charlie, er the business, needs.

Information is the Farrah Fawcett of Architecture and is way too hot for anyone to ignore. You’ll see a lot of pop and sizzle in the Information Architecture business right now and for good reason. Most organizations have voluptuous data repositories just busting out all over, held in place with the skimpiest threads of control. Architecture ensures that we can see everything we need to see, without overexposing areas of sensitivity.

Technology Architecture is neither as glamorous as the Angels of Business nor as sexy as Information, but it has depth, nuance, and facets that one can wistfully admire into extended evening hours. Heaven knows, we’ve all spent a night or two unraveling the mysteries of taboo code.

Architects have to wear many uniforms, play many roles, and engage with many constituents from executive management, to project managers, to programmers in the course of developing a strategy that works both today, and advances the long term vision of the corporation.

Of course, we have to look great while doing all this! By now I’m sure you’ve figured out why some of us only appear in silhouette. I mean, I couldn’t even compete with Bosley.

Like Charlie’s Angels, the three agents of Enterprise Architecture work together to ensure that all factors are brought to bear on behalf of our customers, employees, shareholders, and communities. I think this pretty much proves that the reason I watched shows like Charlie’s Angels as a youth was for their educational value.

Tuesday, September 17, 2013

And the Winner Is...

I don’t know. Seriously. Our contract with Forrester Research affords me the opportunity to be one of five judges in their annual contest to award prizes to organizations for their Enterprise Architecture Program.

The Forrester / InfoWorld Enterprise Architecture Award recognizes EA programs that are positioned to provide lasting value to their organizations. For 2013, they are looking for programs that have taken on the trends of customer-centricity, tech consumerization, digital disruption (of which I have written a lot), and business agility, and have found a way to help their business be successful. This award is not for a specific project or technology implementation, except where that shows an excellent EA program.

As of this writing I do not know the final outcome, I only know which of the 36 candidates made the first cut down to 11 semifinalists, and which of those 11 made my top three. Actually, I know less than that as the names of the organizations are hidden from the judges.

What I wanted to do here was call out the description of one of the candidates to give you an idea of where I see the value of Enterprise Architecture and its proper role in an organization. One of my picks had this description in their application:

EA established credibility in the strategic planning space after successfully architecting critical projects and was moved into the office of the CEO reporting to the Transformation Management Office (TMO). EA was also renamed to Transformation Architecture Office (TAO) as recognition of its importance in defining the transformation footprint.

How cool is that!!

First, EA should be considered a planning discipline, not a project review, operational catch-all, or a technology-centric uber-geek think tank.

Secondly, the whole entire value proposition of EA is to enable transformation from the company which is, to the company which is desired.

The Holy Grail of Enterprise Architecture is to have it aligned with the very top of the organization, and you can’t get much higher than the Office of the CEO. Lastly, EA is about transformation, and combining EA with the Transformation Office is brilliant.

They got my vote!

Wednesday, September 11, 2013

Where do you put the Ugly?

As a programmer I found that the realities of deadlines and costs resulted in one unassailable truth; every program had some ugly code, and that code had to go somewhere. Sometimes this meant a special “Utility” class, or a “Worker” object. Every application had one, and the smart programmers found a way to get all the ugly code into one place. At least then, it was manageable, or as I seem to recall - easier to hide!

As an architect, I find that every opportunity to build reusable objects, systems, or business services comes with an ugly conversation, best summed up as, “The first to the river has to build the bridge.” In short, reusable services tend to cost more than one-time special purpose functions that serve the same “local” purpose. But, asking the first customer to fund an enterprise solution almost always yields pushback.

I worked with developer back in the day who took it upon himself to build a integration pattern for a single business unit, but one that could be leveraged by the enterprise. I’m pretty sure he overestimated some of the work so he could make the solution more robust, customizable, and performant than was actually required by the one business. In those days, that was about the only way to build an enterprise class utility. Lie, cheat, and beg forgiveness.

Should we build a minimal solution for the first customer, thus creating an ugly enterprise service, or do you finagle some accounting trick to fund the right solution, possibly earning the wrath of business users that do not yet see a need for the service?

This tends to be the trade-off; either the solution itself is ugly and not quite ready for enterprise-prime-time, or the accounting is ugly in that funds have to be stashed or amassed from sources that don’t want to contribute, don’t see the need (yet), or want a free ride.

One solution is to skim a few pennies off every IT hour charged to the business to create a technology slush fund. This is very hard in a regulated or cost-controlled environment. Another solution is to leverage one of the Executive Committees to justify shared costs project-by-project. Again, tough to accomplish if the organizational infrastructure is not already in place.

All that being said, I’d rather fight the demons of creative accounting than the ghosts of easy technology.

Sunday, September 1, 2013

Landscaping and Loose Coupling

A few years back, my wife and I bought a shiny new home. The house was almost brand new and the previous occupant had traded a goodly portion of their kid’s future inheritance to a landscaper for a collection of shrubs, trees, and mulch large enough to adorn Hogwart’s Tri-Wizard maze.

So we had a shiny new home, with shiny new landscaping, and shiny new deer to infest our lawn and digest the lower half of the taller organic decorations. One particular tree, a Hemlock, was especially attractive to the indigenous animal traffic, and before the first winter was a third over the tree was half gone. As a child I loved Bambi, and all of her relatives. As an adult I am no longer so afflicted. I have thoughts, desires, and aspirations which would satisfy the retirement fund of at least one Psychologist.

After consulting with a number of plant and tree professionals, we came to the conclusion that the tree was not salvageable as anything but a deer trap. It had to go. The good news is that it was only four years old and so, according to the experts, the roots wouldn't have had time to escape the root ball. For the horticulturally-challenged, let me explain that when one plants a tree the roots are neatly packaged in a burlap sack (a ball) - all tied up so as to easily fit into an easily dug hole (another topic for another rant). Over time; a long, long time so I'm told, the roots will poke through the burlap and take hold in the ground. Since mine was a mere toddler in tree-years, barely into Tree-dergarden, popping it out of the ground would be child's play.

In the vernacular of an architect, the root ball should have been properly coupled and elegantly cohesive. In other words, the object I was trying to remove should have been able to receive the necessary moisture and nutrients through the burlap root ball (it's interface), without spreading into the surrounding environment (i.e. brown dirt, clay, overpriced mulch). Had it been loosely coupled, removing it, and then subsequently replacing it, would not have required my neighbor's Dodge Ram 1500, the anchor chain from an aircraft carrier, and four hours of alcohol-induced colorful metaphors.

Not only did the tentacles of the hemlock escape the perimeter of the root ball, thus becoming tightly coupled to the surrounding objects, but the metal cage that encased the root ball had never been removed. (In the store, the root ball is often held in place by a wire frame - this is to be removed when planting the tree.) In the context of a planted tree, (as opposed to a tree in transit), the metal cage has no purpose - a clear violation of proper cohesion.

Whomever did the landscaping for my shiny new house may have been excellent landscaper, but they didn't know jack about Enterprise Architecture!

Tuesday, August 6, 2013

Developing Standards is the Easy Part - Try Managing Exceptions

Establishing technology standards is not hard. Pretty much any first year college graduate can develop a list of products, vendors, and industry solutions that will enable the delivery of our business requirements. Although, a first year graduate student will likely choose products that are free and easy to use, rather than those having industrial support, but that is a different issue.

What’s hard, and I mean really, really hard, is developing a migration plan that gets you from the current state of whatever and heaven-only-knows to a nirvana state of only approved standards. To be clear, there are solutions to every issue I’ll call out in this post, it’s just that none of the choices are easy.

Here’s an example. Six years ago we deployed an application with six servers; two web, two application, and two database systems. Two years after that we increased capacity on the application and database servers by adding four more (two each). A year later, we added another application server and another database.

Today, we learn that the original six servers are reaching end of life and need to be replaced. This scenario is far more common than you might think.

Understand; half of the servers in this system have not reached end of life. If we just replace the aging servers, we will have to grant exceptions for the replacements or else the newest hardware will have (possibly) incompatible operating systems. At the very least we could have half the application on one version of the OS, and the rest of the app on another.

Additionally, our data center location strategy has changed and as a result the web and application servers “should” be relocated to another city.

So, here’s the difficult situation; do we upgrade all the servers and also replatform the whole system to the “correct” data center? Consider that the cost of upgrading the six newer servers and moving the application to the other data center will more than double the cost of what is actually needed.

The fallacy is that systems reach end of life as a combined unit, rather than as individual elements. You know this not to be true. We have all experienced the situation where a new version of software requires the latest hardware to run effectively. Anyone who took the jump from Word 97 to Word 2000 knows this all too well.

The notion that you can easily get to a new “end state” through incremental attrition is not true. At some point, you either have to upgrade solutions that are not due to be upgraded, or wait until all components are old, with some of them being very old.

Neither of these choices is appealing to an organization that tightly controls costs. So, pick your poison; Keep it cheap and only upgrade what must be upgraded - and approve exceptions. Then approve them again, and again as the cycle just repeats itself. Or, Upgrade everything when the first components reach EOL, losing the depreciation allocation on the recently acquired components. Or, wait until everything has reached EOL, and run the risk of running on components that cannot be replaced, or are no longer supported.

Developing standards is easy; exception management is hard, as you have to balance the desires for consistency/simplicity, versus costs, versus risks.

Tuesday, July 30, 2013

How Much of Your App Separates You from the Competition?

There was a time when having an application at all; the mere presence of an automated solution was a competitive differentiator for a company. I remember when our on-line banking product was considered novel, not so much for unique features, as for its very existence.

As time moves on, market dynamic cause the competitors to adjust, adapt, and catch up. The solutions that separate leading companies from followers become smaller, and so either the previous leaders have to step up, or fall behind a new set of leaders.

The graphic below demonstrates an important element in the architecture, design, construction, and support of market leading applications. As time moves forward, the number of features embedded / provided by a digital product tends to increase, but the percentage of total features that offer a differentiated experience tends to decrease.


New features can mean greater speed, more reliability, smaller size, or better security, but more often than not result in additional capability – which means more lines of program code to support. I’m not aware of too many upgrades where total lines of source code were reduced (although it happens).

We are left with a conundrum of how to support an ever-increasing accumulation of source code and feature set, with a fairly static and sometimes shrinking talent pool, in an environment where (by definition) the amount of competitive differentiation is shrinking.

One of the fundamental concepts that we can take from the physical world of manufacturing and apply to software development is specialization. We might call it reuse, leveraged assets, shared services, or even (broadly) SOA. Nonetheless, we can improve the manageability of our software products by extracting responsibility for the development and support of non-differentiating elements, and centralizing these components in specialized teams.

In addition to freeing up front line resources to allow their focus on true market-leading capabilities; this approach enables the very specialization that can drive costs down and quality and scale up. This is not a new idea; certainly not in manufacturing, and not even in software development.

What’s new, may be just how much of an software application can be considered non-differentiating, or put another way; how much of an application can you build from reusable components.

For most of our applications, the front end (the user interface) is likely the obvious choice to leave in the hands of your business-aligned technology team. The data tier is the no-brainer to encapsulate into reusable calls and services. How about business logic? None of that should be in UI/UX layer. How much of the business logic can be adequately addressed through calls to a Business Process Management (think No Coding) solution?

The number of product features is not likely to go down, so this criss-cross conundrum is going to continue for some time. We need to be engaged in thinking to support business demands for more features, while delivering a code base that is easier to manage, cheaper to support, and just never fails.

Tuesday, July 23, 2013

A Mild Mannered Architect Changes a Reservation

Sometimes an architect has to change their approach when working with others to build a consensus. Sometimes we have to use these skills outside of a classic “architectural conversation.”

If you’ve never worked in a restaurant, you might not fully appreciate the complexity of managing the inflow of customers, table sizes, waiter workload, and reservations. For instance, if three parties come in at roughly the same time, a party of three, a party of four, and a party of 10; how would you seat them if you only had two adjoining tables of five available?

This might seem to be a simple case of first-come first serve, but ask any restaurant manager and they’ll tell you it isn’t that simple.

You can therefore imagine my utter fascination / contempt for the women with the advanced education in third grade mathematics who answered the phone last week at my favorite fine eatery.

I had a simple request. Mind numbingly simple I thought. Here is how the conversation unfolded.

Math-challenged hostess: “Thank you for calling Seafood R Us Emporium; we have mortgage plans for most of our dining selections. How may I help you?”
Mild Mannered Enterprise Architect: “Hi, this is Eric Meredith; I called yesterday and made a reservation for five people at 6:00 tonight. I’d like to change the reservation to four people, and move it to 6:30.”

MCH: “Certainly Mr. Meredith, first let me see if we have any tables that can accommodate your party.”
MMEA: “Wha...?”

At this point, several neural connections have spontaneously combusted, and my ears begin to throb. Before I can speak, she responds.

MCH: “Good luck we can seat your party of four at 6:00. Let me see if we have anything available for 6:30.”
MMEA: “Wha... but... wouldn’t...”

MCH: “Oh, I’m sorry Mr. Meredith; we don’t have any tables available at 6:30.”

Pain courses through my corpus callosum sending lightning bolts between parietal lobes. My left eye is bleeding. Maybe if I give her a hint, and by hint I mean give her the answer.

MMEA: “Sure you have a table available; mine”
MCH: Chuckling, “That’s funny Mr. Meredith, but no I’m sorry, we have nothing available.”

I realize she actually doesn’t see the illogic of her comment. I quickly try to calculate the odds that she thinks that my party of five was going to show up at 6:00 and would have exited the restaurant by 6:25, and thus my table was already spoken for at 6:30. As this is not Wendy’s, she could not possibly anticipate my 6:00 table would be available before 7:30.

Executive brain function kicks in, and I decide to change tactics.

MMEA: “What if we left my reservation for 6:00, and I happened to be a little late?”
MCH: “Oh that would be fine sir. If you are delayed by more than half an hour, just call and we’ll hold your reservation.”

I’m reasonably sure that I didn’t stand speechlessly blinking for 45 minutes; but the mind’s ability to sense time is disrupted during seizures, I can’t actually know. I think I stammered, “Excellent, that would be great.” before hanging up.

Sometimes us architects have to change our strategy to accomplish an important goal.

Monday, July 8, 2013

Are You Certifiable?

I am asked this far more than you might imagine. Often it is after I’ve recalled some obtuse nugget of information like, Q is the only letter that does not appear in the name of any U.S. State.

Over the course of my life, as the conditions have changed I have sought various certifications in disciplines related to the needs and trajectory of my career. This would include programming languages, databases, as well as object oriented, web, and project management venues.

Did you know Russia has more land area than Pluto. Pluto is colder.

In most cases, I could say that my job performance did not significantly change after a certification, although in every case I had a better understanding of why we did the things we did, and I could communicate with other certifiees more effectively.

Should you consider a certification in TOGAF, ATAM, or Enterprise Architecture?

A 2007 survey by Forrester Research found that 65% of responding organizations indicated that a certification in Enterprise Architecture was not an important criteria in their hiring of Architects, although almost half believed it would become so in the future. Gartner’s Hype Cycle for 2012 shows that EA Certifications had not yet reached their Peak of Inflated Expectations.

Did you know 43% of all statistics are made up? 72% of all Internet rumors are actually created by Snopes.com as a way to drive traffic. It’s true, look it up.

An EA certification is not likely to elevate your skills, or those of the enterprises’, to new levels of efficiency, effectiveness, or productivity... overnight.

So, it is worth it?

Education is never wasted, but beyond that consider the benefits to aligning with your peers on nomenclature, trends, priorities, and even broad processes. EA is still a nascent discipline. Everything we do as practitioners to formalize our craft can only improve our deliveries, our reputations, and our performance.

There is also the matter of critical mass. Having one out of 100 architects certified will not create a tipping point for language, processes, or perspectives. I’m not sure what the magic percent is, but it’s probably over 30%. An organization with a significant number of certified Architects should outperform non-certified organizations. Simply put, in which company would you rather work?

Unlike the random facts that invade my conversations (and blog entries), certifications require one to understand the depths of a topic; the purpose, the structure, and the industry’s best thinking.

So the question of the day is, are you certifiable?

Monday, June 24, 2013

Are Your Systems as Hard as Glass?

I have to admit to loving all three Jurassic Park movies, possibly because there was absolutely no chance of it being real. There is a kind of appeal to seeing a live Brontosaurus, or a Triceratops, or a Tyrannosaurus Rex. Appealing..., from a suitable distance of say … 100,000,000 years.

That being said, there is one scene in JPII that just kills me - and I mean that in the best, Alfred Hitchcock, sort of way. I love it. I love that it scares the bejeebers out of me. But, I think it scares me because I’m an Architect.

The scene involves our heroes trapped in an RV and a pair of ornery T-Rexs that are pushing them off a cliff. I have no idea why these carnivorous thunder thighs seem to be ornery, or why anyone would park an RV next to a cliff in a driving rainstorm. Why, I wonder, does it always rain at night on the Jurassic islands? Maybe that is why the T-Rexs are ornery.

As it happens, the double jointed RV ends up with the back half dangling off the cliff, and our leading lady lying on the back windshield. As she begins to slowly push up to her hands and knees, we can see the window glass begin to crack beneath her.

This is what sends a quivering serpent of fear up my neural net. Glass. Cracking glass. Is it strong? Well, in a rigid sort of way, yes it is. But, glass is also very fragile. Strong and resilient is good. Strong and rigid is bad. Glass is strong and rigid - like many of our computer systems.

Glass is strong to a point, but when it breaks there is no “managed landing”, no recovery, no gracious shutdown. Furthermore, any element of a structure that is depending on the glass (now broken) for stability - also immediately fails. Glass has many qualities to be admired, but as an I.T. professional, we must avoid any solutions that mimic the rigid inflexibility of glass.

By comparison, wood is much more resilient. It bends, wobbles, splinters, and even when it breaks leaves lots of connective tendrils on which related structures can depend.

When designing corporate I.T. systems for resiliency, think wood, not glass. You just never know when a nighttime deluge will cause a pair of ornery T-Rexs to go all visceral and invade our sovereign data center.

Tuesday, June 18, 2013

Digital Disruption: Find the Disruptions, Go There

Digital Disruption Lesson #5: Go to where the disruptions are. This is the 5th in a five part series on Digital Disruptions.

Are you concerned about the Elphaba’s in your business? Elphaba is more commonly known as the Wicked Witch of the West. Her business greeting is, “I’ll get you my pretty, and your little dog too!” She is green, ugly, and has a penchant for red shoes and fire. For all her evils however, she at least has the courtesy of telling you her plans. You know that she is after you, and that your time is limited. She even provides the hourglass filled with special sand.

According to George Colony, CEO of Forrester Research, there are a group of students at Stanford University that are also trying to do you in. They want your ruby slippers. They seek to replace your business. They want to find their place in the sun by developing the next successful business. Their inauspicious anonymity is almost more unsettling than Elphaba.

It just so happens that most new business, in some ways, cause the downturn of existing businesses. I recently finished the book, Innovators Dilemma, and it provides an important lesson. Companies tend to falter, not because they fail to listen to their customers, but because they fail to see where their new opportunities are emerging. Successful businesses have their Emerald Cities, watch the corn field, and monitor the Yellow Brick Road; they just never imagine a house falling out of the sky.

In fact, there are countless examples of businesses that failed because they listened to their current customers too much. Customers always want the same things; more of what you’re providing, faster, and at a lower cost. While oversimplified, this is the gist of what most “best customers” ask.

Some companies try to beat this trend by building Centers of Excellence, Customer Data Marts, and Emerging Technology Departments. These are good, but again, they tend to be guided by the wants and needs of current customers, using current products, in the current environment. The Stanford witches are not in your environment, they don’t interact with your best customers, and they’re not concerned with your outdated products.

So how do you beat them? How do you get ahead of your self-created self-destruction curve? Since, by definition, disruption is an external event - you have to go external. Go to where your disruptions will emanate. Go to Stanford, CMU, MIT, or Silicon Valley. Go to OZ, and find Elphaba’s castle.

Digital Disruption Lesson #5: Go to where the disruptions are.

If you think your business will be disrupted by college drop outs with 3D printers, wireless hotspots and social media - then hire some college drop outs.

Get a balloon, go to OZ, look for the flying monkeys. Embrace the disruption.

Tuesday, June 11, 2013

Digital Disruption: Know the Fundamentals of Your Business

Digital Disruption lesson #4: Know the fundamentals of your business. This is the 4th in a five part series about Digital Disruption.

Borders Booksellers operated for more than 40 years, growing from a local Michigan retailer to a national megastore with arguably the largest inventory of books, magazines, CDs and DVDs. But around the mid 1990s, rather than embracing the digital distribution of content, they doubled down on physical inventory. They even outsourced their online sales channel to a competitor, Amazon.

They misidentified the fundamental product they offered their customers. They “thought” their customers wanted books - you know, those physical artifacts with covers and pages that require shelf-space, and if you are my wife, must be dusted once a month to retain their bookiness. What their customers really wanted was information, relaxation, enjoyment, and convenience.

Oh sure, I still love a good book. I treasure my copies of Mark Twain, Sherlock Holmes, and Harry Potter. But, a buying digital copy of The Tipping Point by Malcolm Gladwell at $10.00 off the physical copy price is a little too much inducement, especially considering the Kindle app was free for the Android tablet I had already purchased for other purposes.

Borders missed it. They missed the fundamental product their customers were buying, and so when the environment changed, they didn’t adequately consider the threat posed by online bookstores.

Digital Disruption lesson #4: Know the fundamentals of your business

Somewhere, there is some quiet digital tinkerer, cannibalizing code snippets from previous failed forays into economic graffiti. S/he is not a banker, a retailer, or a giver of advice. Frankly, he’s not even sure how to monetize his idea. He just knows that if his idea gets the attention of the masses, like kittens to crème, he can leverage it into revenue.

He’ll give the core value of his service away for free, just so he can skim off a few partial pennies from each click-through into his Cayman Island accounts. All because S/he accidentally uncovered the assumption you thought was immutable, like … people want books.

People want low interest mortgages with low closing costs, and a hassle-free application, right? No, people want a home they can call their own and do with as they wish.

Consider how the world might look in ten years if these concepts grow at their current rate:

  • 3D Printing / Digital Manufacturing
  • Digital Media
  • BitCoin / Digital Economy
  • Robotics / Digital Services

How will your industry survive? Go ahead, say it... “That idea will never go anywhere, it says so right in my college textbooks.”

Monday, June 3, 2013

Digital Disruption: You Can't Move Too Fast!

Digital Disruption lesson #3: You cannot move too fast. This is the third posting in a five part series on Digital Disruption.

The world’s economy grew from embryonic nothingness at the dawn of civilization to a global output of $4 trillion by 1950. In the next 35 years (1950 to 1985) it grew to $16 trillion. In the ten years from 1985 to 1995 it grew another $4 trillion - the same amount as it grew from its inception to 1950.

You’ve heard of Moore’s law; that computing power (number of transistors on integrated circuits) doubles every 18 months, but have you heard of the storage law that says we double the capacity of storage at the same cost every 12 months, or the law of fiber that says the bandwidth capacity of fiber doubles every nine months.

Between the birth of the world and 2003, there were five exabytes of information created. Today, we create five exabytes every two days. More than 30 billion pieces of content are shared on Facebook each month. More video is uploaded to YouTube in 60 days, than the 3 major U.S. TV networks created in the last 60 years.

In other words, there’s exponential growth in the rate of exponential growth. Computer speed (per unit cost) doubled every three years between 1910 and 1950, doubled every two years between 1950 and 1966, and is now doubling every year.

Do not fear change, growth, acceleration, or the changing growth of acceleration as these are not futuristic boogeymen to be avoided, these are the conditions in which we now live. If we are going to survive and prosper in today’s reality, we have to embrace change, and the pace of change.

Digital Disruption lesson #3: You cannot move too fast.

By this I mean, do not be afraid that your next idea is too far “out there”; if you can find a way to implement the idea, then go for it. For if you wait, the market, the competitors, and your customers will pass you by.

This is not a license to be stupid, or to move without thinking, rather it is an acknowledgement that self-restraint is not an advantage when attracting new markets, business, or customers. Surely, one must have principles and governance relative to quality, integrity, and judgement, but the notion that “the market is not ready,” “we’re ahead of our customers,” or “our partners can’t keep up.” is folly.

If you have an idea to improve customer service, employee engagement, or shareholder value; what are you waiting for?

Tuesday, May 28, 2013

Digital Disruption: Lose the Constraints

Digital Disruption Lesson #2: Lose the constraints that restrict your thinking. This is the second in a five part series on Digital Disruption.

Greenfields, whiteboards, and blue skies; these are the ingredients of an architect’s daydreams. The solutions I can construct when unencumbered by the silly notions of reality, logic, and physics send shivers of endorphins along my cerebral pathways. Commander Data would be jealous.

Until and unless architects become the Gods our egos aspire to be; thinking and doing are separate processes and should be governed by separate constraints. Thinking, imagining, considering, and pondering should not be restricted by mutable “facts.”

Of course, we don’t live anywhere near this fantasyland. Our universe is bounded by big black lines of limitations, cliffs of calamitous cutoffs, and borders of foreboding barricades. In other words, we are trained to think in a box, a box with boundaries we shan’t not cross!

Yes, facts are mutable - they do change. It is a fact that our company has never put email in the cloud. This is a mutable fact. In fact, there are very few immutable facts. The speed of light is pretty rigid, but most everything else is fungible. Most of the rules that govern our work-life are determined by either consensus or edict; which is to say the rules are not determined by physical constraints.

This has led to the age-old question, what is the difference between perception and reality? Answer: Reality can be changed.

We are hostage to our perceptions of what can and cannot be done. We must train ourselves to reject idea rejection on the basis of perceived boundaries. Just because you can’t do a thing is not justification for considering why such a thing shouldn’t be tried.

William Gillette is the man who invented the safety razor. Prior to his solution, shaving was recommended only after registering your Last Will and Testament. It took him years to develop his new razor, sharp enough to cut course whiskers, safe enough not to slice veins. Of his efforts he said, “If I had known how hard it was going to be, I wouldn’t have tried.” Good thing he wasn’t surrounded by smart people telling him all the reasons a safety razor was un-doable.

Digital Disruption Lesson #2: Lose the constraints that restrict your thinking.

Somewhere, close to you is an idea that will significantly improve your business, and the only thing holding it back is that you know better - you know all the boundaries that prohibit it’s implementation. You must reject those boundaries as they are false borders constructed of assumptions, happenstance, and limited visibility.

Somewhere, there is a person who does not know your job as well as you, who is able to make a breakthrough because they are not limited by what you know. You can compete with this person, but only if you allow yourself to think without constraints.

Tuesday, May 21, 2013

Digital Disruption: Unleash Employee IQ

Digital Disruption Lesson #1: Unleash the IQ of your employees. This is the first in a five part series on Digital Disruption.

What does it take to be smart? Are you born smart? Are some people just brighter than others? How can a 10-year veteran corporate citizen today compete with a graduate from Stanford, CMU, or MIT?

Each year, approximately 200,000 high school students take the SAT and score a perfect 1600. These hyper-smart humanoids are quickly gobbled up by their reach schools, proceed into intellectual incubators, and begin churning out challenges to your cushy career.

Why, these cathedrals of higher learning have more eager young brainiacs than YouTube has kittens. Oh, and next year another 200,000 mega-minds will join them. Have you already lost the battle? Where might you find the resources to compete with this onslaught of awesomeness?

Well Dorothy, right in your own backyard.

There are two necessary ingredients to intellectual invincibility. One is raw horsepower, i.e. having a healthy brain that is used to thinking, and the other is knowledge. There is no evidence that today’s homosapients have any more innate brain power than did our ancestors. Better information, yes; horsepower, no. The kids are not smarter than their parents.

But! - your veteran corporate citizens have more, real, and better information. Consider this, studies show that as civilized nations enter the information era, the average age at which patents and prizes are awarded for novel and creative solutions increases. In other words, in a mature information society, it takes longer to acquire enough foundational data to invent new ideas.

Benjamin F. Jones of the Kellogg School of Management at Northwestern University studied Nobel Prizes of sciences and economics over a 100 year period and found that the average age of a recipient increased eight years from an average of 23 years old in 1900, to 31 years old by 1999. As more information is discovered, it takes longer to assimilate it, and then leverage that knowledge to make more discoveries.

According to Geoff Colvin in his book, Talent is Overrated​, the average age of a person’s first Patent has been increasing at the rate of six to seven years per century.

Digital Disruption Lesson #1: Unleash the IQ of your employees.

We need to build the confidence in our employees that their best creative days are ahead of them, and then give them the tools and environment where creativity is exposed, encouraged, and embraced.

I received my first Patent at the age of 54 because my company reached out and asked for ANY ideas that *might* possibly be considered innovative. They then provided attorneys and processes that made it (from my perspective) stupidly simply to apply, and eventually get a Patent.

It works.

Tuesday, May 14, 2013

Preparing for Digital Disruption

Here are five ideas that can help you benefit from the inevitable digital disruption your business will experience.

I attended Forrester’s Annual Forum and had the opportunity to have dinner with Forrester CEO, George Colony. Colony emphasized his message about Digital Disruption and the speed at which we must adapt to change.

During his keynote address he showed the two pictures you see here to illustrate the dramatic changes we are seeing in our world as a result of digital technology. This first picture is of the installation of Pope Benedict in 2005.


This next picture is of the same location, same venue, but this time the installation of Pope Francis in 2013.


Talk about change. In the earlier picture there is maybe one guy with a flip phone camera ready to record the event with a low image snapshot. In the later picture, hundreds of visitors are there to take both pictures and videos, and no doubt, some broadcasting in real time to friends back home.

How might we prepare for a digitally disruptive world in our industry, in our companies, and in our communities. Here are five ideas that would set us up:

In these five posts, I’ll cover each of these in more depth and look forward to your feedback and participation. But first, give some thought to what changes you would make as you look to prepare for the next ten years. Click the links above to read more.

Thursday, May 2, 2013

Go Ahead, Offer Me That One More Time

The background: My wife has been a Type 1 Diabetic for 50 years. Most of us have heard of Diabetes but only know half the story - the half that says, if a Diabetic’s blood sugar drops they need something sweet (like orange juice) to bring it up. The flip side is that if their blood sugar level goes high - just as likely - the last thing they need is more sugar. In fact, they need insulin and physical activity; pronto.

The scene: We find ourselves in a sales presentation where my wife and I are being regaled at the prospect of buying into a program that will yield untold happiness and fortune to us and our progeny for generations to come. The pitch takes way too long to get to the money details, and by the time we are ready to say, “let us think on this outside the confines of this purgatory,” two hours have past.

The issue: That would be two hours of sitting. Basically motionless. Or an eternity of sugar-building, blood-sweetening, life-sucking, artery-clogging, insulin-depleting, coma-inducing, anxiety-building lethargy - in diabetic time. She needs insulin and large muscle activity; pronto. Insulin can be administered through the attached pump, but activity cannot be faked by a vile of drugs and a needle continuously inserted under the skin.

No, she needs to get moving; pronto.

So we thank sales rep Jerry for his presentation and say we need to go, so that my wife, a Diabetic, can get some activity.

“Oh, I completely understand, I’ll get you some Orange Juice” he says, proving quite conclusively that Jerry does, in fact, not understand.

“No, no, we need to get moving to lower her blood sugar, but thank you very much.”

“Wait, let Carl our finance guy give you the bonus offer. This will only take a few more diabetic fortnights to unravel. Here’s Carl.”

“Carl, I’m sorry but we need to get moving, as my wife is a diabetic and..”

Carl sweetly interrupts, “Oh, no need to explain, let me get you some Orange Juice.”

“No Carl, that’s not it... we need to get moving...”

Carl says, here’s Janice, our concierge - who then says, “I understand you’re diabetic. Let me get some Orange Juice..”

We literally ran screaming from the building.

There are many lessons to be learned from this experience, but let us focus on one. There is no "one" solution for every situation.

As an I.T. Architect, it may be that most of your business solutions can benefit from a n-tiered, web-based architecture leveraging your shared hosting platform, a relational database running on clustered VMWare servers. Frankly, that’s a pretty good general architecture, but don’t fall into the trap of being so myopic that you just assume that this one architecture solves all problems.

Take the time to learn other solutions; deeply. Practice them. Understand when, why, and how these alternatives should be employed. Don’t be a one-trick pony or your customers may run screaming from the building in search of ... vodka.

and a little OJ to top it off.

Tuesday, April 23, 2013

You Can't Possibly Read the Emails You Send

Do you actually read your own emails before your send them? Really? Seriously? It’s not possible.

It has happened again. I try to be mild mannered. I do, I really really do. But there are days when the surplus of insanity overwhelms my capacity for self-restraint and something just has to be said.

It started off as a normal exchange between business partners, one asking for something and the other making a counter proposal. So far so good. Then, out of nowhere comes a snarky comment along the lines of “only a moron would be confused.”

Seriously? Your emails are famous for their obfuscation. They should be in the “Clueless Hall of Fame” for written ambiguity and disinformation. A large majority of the words you include are either misspelled or incomplete, or outright fabrications based on some heuristic model of Germanic languages.

Other words or phrases are inconsistent with the context. Even when spelled correctly, there, they’re, and their, are not actually interchangeable.

And let us not discuss the non-existent; the words you meant to type but never actually made it to the document. Am I supposed to glean your intent based on knowing the conversation you were having with unknown persons moments before you graced me with your written verbal vomit.

Maybe if you sent me a decoder ring from the cereal box from which you learned to write?

Would it kill you to re-read what you actually wrote before you hit send? Would that be too much of incursion into your busy day? I realize that my time must be irrelevant considering how much of it you require that I spend deciphering the coded messages you kind-of, sort-of send to me.

How about this; either proofread your missives before you send them, or lose the snark in your replies which seem to be based on my lack of clairvoyance.

They’re, I fel more better. Have a day.

Tuesday, April 16, 2013

Usability is Not an Architecture Quality Attribute

The architecture of an application is often evaluated by assessing its quality attributes; things like performance, security, maintainability  and availability. One topic that often surfaces is whether Usability should be considered an architecture quality attribute.

No one would dispute the importance of usability in the assessment of an application, but is Usability is an attribute of architecture? Usability, in the normative sense, refers to an application’s appearance, intuitiveness, and conformance to interaction standards familiar to the user.

An important book on the subject of Software Architecture is the SEI Software Architecture in Principle by Bass, Clements, and Kazman. In their first edition, they include the following:

Making a system’s user interface clear and easy to use is primarily a matter of getting the details of a user’s interaction correct … but these details are not architectural.

This would support my proposition that the normative definition of Usability relates to the user interface, as opposed to structural concerns like performance, security, and availability.

In subsequent editions of the book, they not only refute their original assertion, they include a section titled, “Usability Mea Culpa (or that’s not Architecture),” in which they decidedly changed their position and claimed that Usability is an architectural attribute.

They should have stuck to their original guns!! Usability is such an important concern; it should be elevated to a level as equally important, but separate from, an application’s architecture.

That being said, there is a definition of Usability that would fit under the architecture umbrella. You will not use a system you do not trust. Trust stems from things like availability, performance, security, and integrity. If you enter data and it gets garbled, it does not matter how elegant the interface - you will not use the system again. It is in THIS capacity that architects should concern themselves with Usability.

There is an argument to be made that experts in Human Computer Interfaces (HCI) engage in Usability Architecture, but that is not the typical path of the debate. Generally, the Usability conversation is concerned with consistency of interface; both in terms of industry accepted norms and consistency throughout the application.

Usability is critical to the success of software systems. At the level of granularity and detail at which most architects function, Usability is addressed via performance, integrity, security, and availability, not user interfaces. While Usability (user interface) is at least as important as architecture, it is not an Architecture Quality Attribute.

Tuesday, April 9, 2013

Johnny Carson as Carnac the Magnificent Architect

Johnny Carson once claimed that his favorite joke went like this:

Imagine the African Savanna in late August. In what was a large lake, but is now a relatively small mud-pool sits two hippos. They are submerged to their eyeballs, which appear just above the surface. The air is thick with humidity, and there is no sign of movement in the air, the grasses, or the animals. The first hippo looks at the other and says, “I just can’t get it through my head that it’s Tuesday.”

Johnny has a strange sense of humor.

Thankfully he also gave us Carnac the Magnificent, the mystic who divines answers to questions in sealed envelopes. For instance, Carnac divines the answer, “Eleven.” to the sealed question, “What is the combined total of Bo Derek and Phyllis Diller?” Here are some more...

Answer: “Timbuktoo”
Question: “What comes after Timbukone?”

Answer: “Sis, Boom, Baa.”
Question: “What is the sound of an exploding sheep?”

I don’t care who you are, that’s good stuff.

Humor is a lot like architecture reviews; one person’s perfect is another’s total miss.

Sometimes, after an Architecture Review Board meeting, someone will say, “Well, that should never have come to the ARB.” I suppose it is one of those in-the-eye-of-the-beholder kinds of thingies. Turns out there are two extremes of projects that will invoke that response.

First, is almost any project that, after an hour of business, architecture, and technology review, the Boards finds everything to be satisfactory. It’s almost as if the reviewing architects are thinking, “If I don’t find something wrong, this has been a waste of everybody’s time.”

Seriously? I would agree that a solution that employs only pre-approved components, reference architectures, and shared systems is overkill for an ARB. There are very few of these. Ever.

The second kind of review that generates “Why bother” commentary is one where the Board finds multiple, multiple issues that generate multiple action items. When this occurs it is often because some assumption that turns out to be invalid.

So... if the Board finds multiple issues - the ARB was a waste, but if the Board finds nothing, well then the meeting was unnecessary. Ow, ow, my ears are bleeding.

For some, the only review which satisfies the mission of the Board is one with 4.2 issues, 2 concerns, and one observation. If only Carnac could identify those before we waste everybody’s time.

There’s no predicting which proposed architectures are going to be perfect, and those which will require improvements - that’s why the Board actually takes the time to review them. Last month we held two ARB meetings, with a total attendance of 130 individuals hearing about standards, expectations, remediations, and rationale.

I don’t care who you are, that’s good stuff.

Tuesday, April 2, 2013

Enterprise Architecture has more than one true definition (Sorry Gartner)

I’ve had the opportunity to attend at least one Enterprise Architecture forum / workshop / conference every year for the past ten, a few of them as a speaker. I recently had the good fortune to be among a group of contest evaluators, reviewing submissions to an industry award for Enterprise Architecture. I’ve seen behind the curtains of a lot of EA programs.

Most Enterprise Architecture Programs are really IT Architecture Programs for the Enterprise. First, this is not a bad thing - and I’ll cover why that is in another post. For now, let’s understand the difference between the two and you can determine which program you have.

I am also a martial artist, having studied the Korean art of Tang Soo Do for almost twenty years. I’m a certified teacher and a fourth degree Black Belt - which is to say, I’ve seen the inner workings of the martial arts business.

I have had many conversations with the proprietor of the local Tang Soo Do franchise that could be considered Enterprise Architecture, and yet not a single one of these conversations involved a computer, a computer system, or I.T.

EA is about, literally, architecting the enterprise. Where are your customers, how do you get more of them, and how do you get them to return (or in the parlance of martial arts; not quit). Most martial arts businesses lose over 80% their students before they reach Red Belt level and retaining these students is critical.

A martial arts program can be a corollary for almost any other business - there are elements to most enterprises that have nothing to do with Information Technology. In today’s environment, it is hard to conceive of a business model that does not rely on IT, but to understand the purest definition of Enterprise Architecture; you must separate the business from IT.

Enterprise Architecture is about the fundamental elements of the business, which may and often do include IT, but only as a facilitator of the business - not the core element of EA.

Most companies do not, by this definition, have an EA program, or stated differently, many organizations do not have a contained, singular function or department that operates by this pure definition. Enterprise Architecture is spread out amongst the CEO, the Board of Directors, the CFO, the Manager of Operations, Marketing and HR.

By contrast, many organizations do have an “EA program” that focuses on aligning Information Technology assets and capabilities with the businesses that utilize them. In short the program is really delivering IT Architecture for the Enterprise. Programs of this nature should not be considered weak, immature, or underperforming (Sorry Gartner).

Much of what we see at industry conferences and read from the leading research houses suggests that a true EA program must and only fits the first definition - thus many EA practitioners feel as underachievers, constantly trying to break the ceiling that inhibits them reaching the “one true definition.” I would suggest that delivering IT Architecture for the Enterprise is a noble and valuable endeavor.

Tuesday, March 19, 2013

T'was but an Ounce of a Moment.

Did you know that terms like “Fortnight” and “Ounce” indicate units of time? Furthermore, did you know that seemingly ambiguous terms like “Moment” have actual measurable, concrete definitions? Did you also know that finding arcane facts is a necessary skill when collecting business requirements?

Business user: “I can’t really say exactly when, but if we make the user wait more than a moment, they’ll just click off the site and go away.”

Architect: “Actually, if the user has to wait more than an ounce of a moment, they’ll click away and typically not return before a fortnight.”

Business user: “You’re very strange. Handsome and funny, but very strange.”

While reviewing the architecture of an online business service, we discovered that we were able to deliver the terms of a loan (interest rate, length, payments, …) in under seven seconds. This was good because our terms would then be compared to other bank’s terms side-by-side. If our terms were delivered too late, they would be ignored by the client software and we would lose the opportunity to be selected.

As it turns out, a moment is a medieval unit of time comprised of 1/40 of an hour, or 90 seconds. A moment is further comprised of 12 equal ounces, or 7.5 seconds.

I’m not sure why our medieval grandfathers needed to measure things down to the 12th of a moment, but it is interesting that hundreds of years ago we needed to express patience and urgency in elements greater than a second and less than a minute.

In the case of the aforementioned architecture (and how many times have use used the word aforementioned today?), we discovered that after a data center disaster, all of the servers needed to restore the loan term service would be recovered within a short period of time. (way less than a fortnight).

But … and this is critical..., under the “disaster recovery” environment this term lookup service would likely not deliver an answer in an ounce of a moment. In fact, the response time was likely to be over 30 seconds. A veritable ⅓ moment.

For the medieval illiterate - In a disaster recovery scenario, the loan term service would operate slower; and while still functioning, would respond so slowly that our offering would never be seen by the customer - we would be operational (technically), but essentially out of business.

Understanding how our customers experience time is and always has been an important element of staying in business. Whether we are committing to a sharper axe blade or an auto loan interest rate, we need to commit to, and deliver a rapid response. This must be true in normal business times as well as after a disaster.

Tuesday, March 12, 2013

Having Standards and Going Broke

One of my favorite surveys I use when talking to a large audience, is to have the house lights brought up and then ask, “Would everyone here who personally thinks that they are irresponsible and unreasonable, please raise your hand.” It always gets a chuckle as invariably three malcontents self-identify.

Everybody believes their perspective and judgement is both sound and moderate. So when I ask an I.T. person if their technology standards support their business goals, they always answer yes. Oh sure, they'll admit to having room for improvement, but all in all their standards meet their businesses needs.

I've yet to meet a technology manager who says, "I'm clueless. Frankly my business goals for the next three years can't be all that different from the last three. Got to go now, Siri just reminded me of a 3-way video call in ten minutes on my iPhone." /irony

So, you have to drill a little deeper with a different question.

“Do your technology standards meet the needs of 80% of the requests you receive?” But, don’t stop there. Keep going with, “Do you believe your standards will meet 80% of the future requests during the upcoming investment period (typically 3 years)?”

Standards must balance the goals of the support side (minimizing risk, costs, and variance), as well as the business side, (maximizing flexibility, capability, innovation). Focus too much on the former and you get reactive efficiency; too much on the latter and you have unrewarding complexity.

Enterprise Architects must embrace the notion that technology standards are a means to a goal, not the goal itself. Having tight standards that are brutally enforced will likely get you in the Architecture Hall of Fame for driving your company broke at record speed.

If you are looking to establish standards, review the last year, or quarter of requests you filled and see what patterns emerge. See if you can’t draw a line between the majority and the minority of requests. Know your customer (KYC).

This analysis should be the cornerstone of your executive and business communication - you need to establish standards based on the future needs of your business. If you do, you’ll garner support and appreciation, and establish an effective counter-argument against silly exceptions.

Tuesday, February 26, 2013

Is Enterprise Architecture a Technology Function?

I did well in school (after High School cough, cough). I especially liked the sciences and courses that involved analytical thinking.

If A = B, and B = C, then A= C.

This is a simple axiom that most of us learned when we took that one required course in logic. I’m going to share another one with you that is a bit longer - but first, a little background.

Every Enterprise Architect I know either started in Information Technology or worked in I.T. for some time. The natural assumption is that Enterprise Architecture is a function of the I.T. department. Is this correct? If not, why not?

I’ve written before about the differences between Enterprise Architecture and “IT Architecture for the Enterprise.” To further the understanding, let me state that Enterprise Architecture is related to I.T., but only to the degree that some goals of a business can be achieved only through the proper use of Information Technology (I.T. or IT).

Enterprise Architecture could have been a useful profession at the time of Christopher Columbus, long before computers. In his aspiration to improve trade with the East Indies, Columbus attempted to find a shortcut across the globe. This is Enterprise Architecture; understanding what capabilities are needed to achieve a business advantage.

Columbus' plan would have worked had it not been for that pesky continent in the way. If only he had talked to an Enterprise Viking first.

In the modern era, computers dominate the underpinnings of almost every aspect of business operations, so it is only natural that Enterprise Architecture frequently leverages I.T. in the delivery of new solutions.

This is a trap. Here’s the logic - take a breath...

EA frequently leverages IT because IT is an important capability of Business, not because EA is an element of IT. Stated another way, EA is an element of a Business that often leverages IT.

Or, most succinctly still; EA =/= IT.

Every organization needs an Enterprise Architecture function (even if it’s called something else). Gartner Group, Forrester Research, Microsoft, IBM, and leading organizations across the globe have found that the most successful companies elevate EA out of I.T. to drive innovation, capability, and meet business aspirations.

Tuesday, February 19, 2013

I'm Not Ready to Bid Farewell to Three-Tiered Architecture

As a young man, Dad taught me how to shake someone's hand. Line up the thumb slots; make sure the fingers wrap around the pinky, hold firmly but don't squeeze; pump the hand three times. My older brother showed me an alternate handshake that involved wrapping your fingers around the other person's thumb. Cool, i.e. better.

This handshaking progression kept changing until we reached a point where shaking hands was more of a secretly coded series of gestures using fingers, knuckles, fist bumps, elbows, toe nails, shoulder taps, and pinky swears. OK, I made that last part up. Still the complexity of saying "nice to meet you" has overwhelmed my fine motor skills.

Complexity has infected application architecture as well and I'm wondering if it is it time to declare the death of the three tiered, or n-tiered architecture? Has it become too simplistic?

There is an architectural discussion going on that says that although the three-tiered design continues to be a sound conceptual model, in a very practical sense it has been replaced by models represented by many-to-many end points. Gartner Research has a wonderful article out on this.

Consider that a modern application is comprised of a web application that may be divided into static web parts and one or more application server parts. These applications tend to be front ended by browsers, mobile devices, B2B process engines, social applications, and other devices such as voice response units.

These same server-side business applications may have as their back-ends, a relational database, CICS transaction, BPM processes, flat files, document repositories and / or other B2B process engines. Conceptually, these are three-tiered applications, but practically these are dynamic, multipoint, event-driven, processing environments.

I am willing to bet that since the one tiered / monolithic architecture is still used today (defined as a single application that processes as a batch the records in a flat file), that two and three, and n-tiered applications are going to be around a long time. In fact, my retirement strategy is counting on having endless part time work fixing these apps, so please don't kill them off just yet.

I’m not prepared to declare the death of the three-tiered model (Please, please - I’m going to need the work), but reality suggests we embrace the newer paradigms, which should translate into better development methodologies, QA processes, and real-time monitoring to say the least.

Tuesday, February 12, 2013

The Best Laid Plans

For 34 minutes the Super Bowl was suspended; which is OK, because it’s not like it’s the most watched sporting event in the United States. It was a cloudless night with a bright ¼ moon; giving those OUTSIDE the domed stadium some measure of light to find their bottle openers. You would think that someone would have planned for this.

According to Dwight D. Eisenhower, “Plans are nothing, but planning is everything.” Given that he was a Five Star General during World War II, Supreme Commander of Allied Forces, had responsibility for planning and supervising the invasion of North Africa in Operation Torch in 1942 and the successful invasion of France and Germany in 1944 from the Western Front, and later became the 34th President of the United States - you might imagine he knows something about planning.

You might also think that someone on the Super Bowl committee (maybe an electrical architect) might have thought of possible power outages. Good news; they did.

Someone actually considered the possibility that a power spike, power drop, power interruption, hiccup, gap, chuckle, burp, or holy-bat-bang explosion might take out the lights. So, these geniuses installed an extra relay switch, just on the off chance that one of the aforementioned power poops didn’t stink out the joint.

The relay failed. Of course it did. This is a tenant of Murphy’s laws of electrical equilibrium. Failure will occur in the one piece of equipment designed to prevent failure.

Remember, Murphy was an optimist - this gets even worse than you thought. See, there was a contingency if the power (against all planning) went out, there were emergency electrical systems, driven off batteries and generators designed to immediately kick in so as to maintain some semblance of calm and order.

One row of emergency lights remained on. Cool. The public address system however was not considered necessary. So while some attendees could see some halls and stairs (elevators and escalators were off) - while there was some limited light, there were no instructions because - well, those circuits weren’t necessary. Brilliant.

After several days of analysis, review, and world-class finger pointing the local power company (Entergy New Orleans) proudly concluded it was the manufacturer’s fault. The vendor who supplied the relay was to blame for this global goof-up.

The vendor, Chicago-based S&C Electric Co. however, says their equipment operated exactly as the administrators configured it and that if it had been correctly configured the relay would never have tripped and the lights would have remained on, the 49ers would have lost by a larger margin, and Joe Flacco would be considered the greatest Super Bowl quarterback this side of the Milky Way Galaxy.

The audience blamed the halftime show, architects blamed the installers, the installers blamed the vendor, and the vendor blamed the administrators. Sounds like an IT shop.

Five points if you recognize the truck.

As a result of the 34 minute outage, CBS sold more commercial time and recorded the highest number of viewers in the history of the Super Bowl. Almost sounds like it was planned.

Tuesday, February 5, 2013

Drawing a Line in the Sand

I rarely have trouble sleeping, but when I do it’s over topics like; which is more important, the bow or the arrow? A crayon or a coloring book? A recipe or a stove? Both! Neither! Aaggggggghhhhhhhhhhhhhhhhh!

Each of the above is important, and without their counterpart each becomes important only in an academic sense. Such is the relationship between Architecture and Implementation. Consider the following statements and determine which ones are statements of architecture:

  • A large financial services company sells and exits its mortgage business.
  • Placing an application domain controller in front of a set of clustered web servers.
  • Using MQ Series, with a persistent queue to send messages between applications
  • Maintaining user authentication credentials in an application-specific database.
  • int x := max( a, b );
  • Utilizing an open source framework to provide user experience enhancements including data validation.

As Admiral Ackbar would say, “It’s a trap!” Each of these statements could reasonably be the result of, or the cause of, a conversation of architecture. See the line of programming code above; “int x := max( a, b );” - as low a level as this single Java statement is, there is an inherent architecture to it, and a reasonable architecture debate could ensue.

In any solution design there are more decisions to be made than there are roles or people. Therefore, we have to draw a line at some place to distinguish between the responsibilities of architects, and the responsibilities of developers.

But let’s make sure we don’t confuse “roles” with “importance”. A bow is no more or less important than an arrow. An “architect” is no more or less important than an “implementor.” An architect’s work should precede that of an implementor, but that is a attribute of sequence, not importance.

So which of the above bullets are architecture? They all are, with a caveat. This graphic shows the various sub-disciplines of architecture; Technology, Information, and Business.

We add to this - a designation called, Application Design. Note that even though we have stated all of the bullets above are architecturally significant, we are drawing a line above the design examples. This “line in the sand” illustrates the separation between what we call architecture and that of design. This would represent the distinction between what we would expect of a full-time architect, and the design decisions expected from a Lead Developer.

Full-time architects will be allocated to a specialty such as Technology, Business, and Information. Lead Developers will often span all of these areas as implementers. One additional nuance that makes this separation of responsibilities even more delightful is that workload management and balance will often require that Lead Developers function as architects. That, however, should not muddle the proper distribution of responsibilities. A person with a title of “developer” should not be excluded from using their skills as an architect, assuming sufficient experience. Full-time architects should be leveraged on initiatives where the work-set, demand, and time-requirements call for it.

In summary, there is plenty of important work to go around, yet it is important that we assign appropriate expectations to appropriate skills. Many design options and alternatives are rightfully aligned with Lead Developers, while architectural decisions should be deliverables of full-time architects. Time, demand streams, and priorities may cause individuals to fulfill different roles - that is OK.

Follow by Email