Infosec, Cloud & Money

I disdain talking about something that is hot at the moment, whether through research, adoption velocity or glamorous marketing. However after countless meetings listening to people trying to figure out the hype, I feel the urge to comment on a couple of ideas that are and will continue to be overlooked due to slick marketing materials, excellent websites, gifted sales people, impatience on the part of the customer to get a problem solved and ignorance in general by both parties. It is the challenged normal problem of person with problem seeking solution from vendor (or anyone perceived to be magical). In this case it is the individual and juxtaposed ideas of cloud computing, information security and money.

First let's talk about the premise that all customers need to find a fiscally responsible infrastructure solution.

Getting a Return on Your Leased/Rented Vendor Infrastructure

As for cloud computing ROI, there is no contest [Skilton]. The reality of 'renting' or 'leasing' virtualized elastically allocated space inside a vendor infrastructure receives no economic contest when compared to alternatively buying, administering and owning your own hardware infrastructure in /most/ cases.

We might be able to make a case for other economic solutions in the customer favor should we talk purely about commodity-based load-balanced farming, open-standards solutioning and lean supply-chain implementations; but when it comes to business and customers, it is true that we all get what we pay for (or deserve) in the end. And we have to know how to optimally use what we pay for as well. Then we have to discuss associative staffing, second and third-order operationally reliable infrastructure, processes, procedures, skills training, human resource management and the list goes on. There is no "buy an appliance" or “software package” and be done conversation. Like marriage and family, it comes with relatives. Owning your own infrastructure is cost and effort. Period.

Do the math. Leasing infrastructure, that comes with all the trimmings of back-up/recovery, redundancy and fail-over, 24x7 trained support staff and so on is, at face value, cheaper than owning it all yourself.

We can mathematically prove the ROI model for virtualized elastically allocated leased space in clean-room modeling. Yes, I said clean-room. We'll still need years of actuality to validate our initial hypothesis as should be expected. We cannot pretend to understand the math models of cloud without a more diverse array of customer types and attributes across a longer period of time. We'd like to. We cannot. Cloud isn’t just about the hardware. The hard infrastructure math is simple compared to the less quantifiable virtualized spaces and associative variable cost software stacks. We currently have no significant reason to disbelieve the math or the logic. However, time is the key. And we should expect that Marketing and Sales teams alike will no doubt try to compress that timeline by attempting to give us a premature sense of confidence.

Second to cloud ROI is information security. Or is it actually first? Nonetheless, sitting inside a verifiably certified physically and logically secure data-center 'somewhere else' is our second order of business. We’ll focus on the logical side only at this point for simplicity. However, one should note a complete risk management program includes both logical and physical security.

Understanding ROI for Proper Information Security

The math model for information security loss is still young in our experiential history [Berinato]. Many people I've encountered are still learning Moore’s law and its economic implications, how to perform company start-up valuations, begrudgingly accepting data suggesting defect prevention is cheaper than inspection and detection [Berinato], still don't want to believe Brooks' mythical man-month logic [Brooks], aka Brooks Law, still don’t know about, accept and/or understand project estimation implications of the McConnell documented cone of uncertainty factors (or even the predecessor NASA data) [McConnell], and romanticize having hot:hot fail-over while not wanting to spend a dime to implement it. Understanding leased elastic virtualized infrastructure math is something else to add to leadership knowledge "to-do lists". And the complexities of combinatorial testing against software versions in the stack against end-user OS browser combinations will not get easier, they will get harder now that everything will be virtualized. Exactly when is it “my” fault and when is it “your” fault there was a breach, fault and failure? Was it a stack issue? An interoperability issue within the stack, across stacks, across VMs? What? Prove it.

Vendor CFOs will want to look at an elastic virtualized machine (VM) solution as a multi-tenant building complex for rent. Straight math. Customer CFOs will still be forced to look at their slice of the pie as standard capital and operational expenditures located “off-site” with contracted staff and tight SLAs. Neither will consistently or effectively calculate preventive versus detective versus breach and response economics in terms of VM to VM breach on a single physical instance. Vendor CFOs will likely handle breach through customer-signed liability and fair-use statements while Customer CFOs will attempt to handle this scenario through vendor-signed SLAs and internal board-room whippings. I hope I’m wrong. I’d rather see purposed preventive measures on both sides to mitigate the need for executing the SLA and liability contracts. Some will simply adopt the logic that it’s easier to call a lawyer after a breach than it is to purposefully plan for, mitigate and prevent variable breach scenarios. Hard work is hard.

At least for now, based upon the news, tracking organizations and initial calculations by those that can, we know that one information security error will cost tens of thousands, millions or even billions across companies and industries due to miscreant mis-use of said data. We also know the second and third-order impacts will be personal, corporate, national and international, sometimes at the same time. Problems with leased VM space will impact legislation at the levels of countries. However understanding this math (cost of loss) requires more time and maturation to harden up the actual algorithmic risk:return:loss cost-model [DATALOSSdb] and many people simply do not know how to create and manage a fundamental information security risk diagrams for their operation [Harris], vendors and customers alike [DATALOSSdb].

Now in all fairness and anecdotally, it has taken us easily twenty years to evolve the software economic models of Boehm, IBM, NIST and others. Yet finding a CFO capable of including mature software economic theory in annual budgets is like looking for a needle in haystack. Either they understand it, or they simply log it in the Profit & Loss ledger as a “Research & Development” catch-all line-item with the ideas of preventive versus detective versus production fault and failure costs being completely lost in the shuffle. And finding an entrepreneurial CEO that cares past the lipstick might possibly be even harder. ‘Cloud’ marketing may well be ahead of useful reality so those catch-all line-items may get a lot of use in the coming years.

There are companies and technologists who have been using virtualization for years. It’s not new. However, it is my opinion that the masses, i.e. general consumers, do not fully understand what meal they are ordering when signing up for managing their domestic and/or multi-national business for cloud solutioning. It is additionally my opinion that the vendors do not fully understand the extent to which they will be liable in a “sue-your-neighbor-at-will” society for things yet to come. We’re all walking in smiling, side-by-side, whistling a happy tune. Politics includes the blame game. Cloud solutioning will amplify the “it’s not my fault” behavior and we’re going to see mess upon mess in the news and courts.

We have hard-math for hardware. We do not have hard-math for information security risk:return:loss scenarios. We have formulas [Harris]. Not enough information security people know them, let alone CxOs, managers and staff. We need more time, data and purposed education. So, how do you determine your own information security needs and in particular, sniff out experts from amateurs?

Determining Proper Information Security Measures

Snake-oil salespeople are all going to claim they have [ha.ackers] everything you need to be safe already in place. You hope that by going to a specialist they know more than you. You hope that because someone is a vendor in the particular field of your present interest that they are the expert. You hope. Ladies and Gentlemen, in the world of a new business markets, vendors will come out of the walls and every single one of them will be an expert. We’re going to be swimming in ‘cloud experts’ for quite some time just like we’ve been swimming in ‘Agile experts’, ‘Rational experts’, ‘SDLC experts’, ‘Web Programming experts’, ‘Start-up experts’, ‘Requirements gathering experts’, ‘financial forecast experts’ and ‘national security experts’ for decades. Strap in, there’s a new roller coaster in town.

Make vendors prove it.

It is far easier to prove a vendor has physical solutions in place than logical ones. They can show you glossy pictures of arbitrary hardware stacks, network topologies, data-centers, people in suits and their associative CVs, armed guards and Trolls that guard the bridge over the moat that’s home to a sea monster who eats bad people, but they can’t show you pictures of information security measures they have in place to protect you, your company and your data. They can tell you, but unless you are an information security junkie and past tech-head, what they say may sound impressive to you, but actually be meaningless blather. So we have to rely upon third-party consultants, certification, audit and test organizations to validate an organization's implementations against current industry standards, trends and bodies of knowledge. It is non-negotiable for those with the presence of mind to think with greater depth and breadth than the pretty hardware stack in a locked cabinet and cage with blinky lights.

Ladies and Gentlemen, you want to know about the vendor company’s processes, procedures, certifications, audits and re-certifications just to start the conversation. We’re not even discussing the main course of standard operating procedures for production support, monitoring, response time and resolution, penetration tests, and social things like asking for a list of other customers the vendor may already have that forced high-information security standards of implementation and so on. For example, if a vendor has a Federal Government customer, we know they had to jump a certain height already. Conversely, if a vendor has a local mom and pop shop as a customer, the bar is likely low. Whether it is too low for you is up to you to determine. And whether you’re willing to fund your vendor’s education and infrastructure maturation journey is a business risk decision on you’re part. It is not the nature of vendors to walk away from gigs because they aren’t qualified.
  1. Ask a vendor if they have information security experts on staff. If yes, ask to see their CV. Ask about their information security qualifications. You want to see information security on-staff having multiple years of technical experience and with one or more of the following certifications such as CISSP, CISA, GIAC, etc. Ask to see their certification numbers and where it can be verified online or at the certifying organization in question.

  2. Ask a vendor where their data-centers are located (address), what physical security procedures are in place managing physical access, and what information security certifications exist for said structures. You want to see certifications and validated third-party compliance statements against things like SAS70, ISO, IEC, MIL-SPEC, etc. Ask to see the actual certification papers. Ask to see the results of the last audit(s) and proof that any deficits have been addressed. Physically visit the data-center when possible.

  3. Ask a vendor what information security certifications their company has, when they were received, when the last audit occurred and when the next audit is to occur. Ask to see the actual certification papers. Ask to see the results of the last audit(s) and proof that any deficits have been addressed.

  4. Ask a vendor if and when they’ve hired a third party organization to perform penetration tests against their infrastructure AND any software applications they will be providing for you. Ask to see the results of the test and for proof that any deficits found were addressed. If they are secure as suggested, a little penetration test shouldn’t scare them, but rather embolden them.

Highly regulated industries require on-going evidence of audit/test, deficit and fix; so can you. If the vendor wants to play in your industry, make them pay for their own certs, tests and accolades. Everything I’ve said in this article is independently verifiable on your own. Don’t take a vendor’s word for it. Do your own research or hire someone to represent you in this endeavor. The cost of doing it wrong will be more expensive than hiring someone to do it right on your behalf. Think about that.

As for cloud, return on investment and information security risks and liabilities, only you, the customer, can determine your risk and funding tolerances. Only you, the customer, can sift through the riff raff to determine a proper vendor associatively. After you understand your risk, you're better equipped to determine your solution possibilities by looking at multiple vendors. If you need help assessing your risk and funding tolerance, ask a third-party technical security consultant, not a cloud vendor. If you don't know your risks but believe you are ‘smart’ or have ‘smart’ people on staff, good luck.

Preventive, detective and corrective information and physical security measures are never ‘done’, they are only ‘done at this moment’. The ‘next moment’ may define you.


Atwood, Jeff. "The Mysterious Cone of Uncertainty". June 28 2006

Berinato, Scott. CIO. “Software Security: The Bug Stops Here”. May 15, 2003.

Boehm, Barry W. Software Engineering Economics. Prentice Hall. 1981.

Brooks, Frederick P. Mythical Man-Month. Addison-Wesley Professional. 1995.

Construx. "The Cone of Uncertainty".

DATALOSSdb. Open Security Foundation.

ha.ackers. "The Effect of Snakeoil Security".

Harris, Shon. All In One CISSP Exam Guide. McGraw-Hill. 2010. Fifth Edition.

Jackson, Kevin. "Open Group Publishes Guidelines on Cloud Computing ROI". May 2, 2010.

McConnell, Steve. "Software Estimation: Demystifying the Black Art". Microsoft Press. 2006.

Skilton, Mark. "How to Build ROI from Cloud Computing". December 9, 2010.

Thibodeau, Patrick. ComputerWorld. "Study: Buggy software costs users, vendors nearly $60B annually". June 25, 2002. 12:00 PM ET.


Many years ago when I feigned interest in the technology industry I had a well-seasoned friend spend ample time with me teaching me the ins and outs of DOS shell scripts, syntax, leveraging system resources and the like. He took me into the COBOL client-server world with him that eventually led to a myriad of other languages and platforms thereafter. I ate everything in sight as fast as I could be fed; and then everything else I could find even when not with this more experienced bloke who was taking the time out of his life to teach a new puke how to survive. Then as I kept moving, I made another friend who threw me into the Unix pools we were using at the time and he upped the ante with shell-scripting languages, flags, man pages (which I read for fun without fail even today), system processes and so on. These paths later prepped me for discussing disk and system utilization, environment architectures, language to system utilization symbiosis (and antithesis) and I was, and am, forever hooked. It is because of people smarter than me who took time to teach a kid who needed his arse kicked through the wall frequently that I improved. Every time I thought I knew something I would get smashed by the senior again. It proved to be a relationship that worked for me. Learn or die. I loved the binary behavior.

One day I received something I didn't expect in the form of feedback. "I already told you how to figure that out, go RTFM and come back to me when you think you can keep up!" What happened to the love? What happened to the "I can't get it please show me" thing we had going? What happened?

Here's what happened...

These mentors that I've mentioned above aren't the only ones I've ever had. I've been amazingly blessed with outstanding, professional, very intelligent people with the patience, kindness and consideration to take a know-nothing, should-have-had-my-arse-kicked-more-often-than-I-did puke kid and turn him into something that was useful -- and eventually autonomous. In every single case, the people that knew how to mentor usefully gave me just enough information to head in a particular direction without telling me the next step. In every single situation I received just enough feedback to get me back on track without giving me the answer to the problem at hand. In every situation I had been coached and guided on 'how to learn' without being told 'how to think'. Their goal was for me to learn and lead. In every situation that I can remember, I've had mentors who knew when to talk and when to shut-up. And in every situation the end-state expectation was that I'd been shown just enough and it was hereafter time to RTFM and self-evolve or leave.

Each person only gets so much mercy and grace in the mentoring relationship. After you've been coddle, loved, coached, shown, hugged and kissed you get graded. You get graded on how well you capitalize on the investment given you. You get graded on how well you learn, evolve, apply, adapt and improve upon that which was given to you as a gift -- a gift that was crafted by the hands of the person sharing it with you. After such a gift has been handed down to you, it is your job to make it more than it was through careful, daily attention. Anything less than this makes the investment in you a waste. You owe it to the people investing in you to be a rockstar. Otherwise you're nothing more than a free-loader looking for the next relationship from which to leech and move on after host-death masking your lack of knowledge, experience and ability to rock.

You owe to each person who has ever believed in you, invested in you, coached, mentored or otherwise taken you under their wing to bring you up in the way of the warrior. You owe it to yourself. You even owe it to the people who taught the person who taught you. You owe. What you've been given is a privilege.

So please don't be offended when I tell you to go RTFM. I'm not dissing you. I'm reminding you of your debt to all the people who came before you so that when you're successful you'll better understand why its your job to mentor the next puke kid that shows up thinking he/she knows everything. There is a right of passage that needs to happen ensuring that each tenured craftsman out there in our ranks went through the knotholes that make a salted, autonomous, problem-solving technical craftsman. Being a g33k is an earned-right that only happens through purposed diligence.

So I'm telling you right now, "Go RTFM and be worth the time someone invested in you."

Refactoring, Ctrl-C/V & Relativism

I was just reading a friend's ever-clever bitstream on copy and paste behaviors while thinking through a number of things I've been experiencing and studying. After too much tea and too much reading without a break, I accidentally juxtaposed the ideas of refactoring, copy and paste and relativistic decision-making as they do or do not contribute to societal evolution and legacy. You might need ditch weed for this. Hold on.

The idea of refactoring as it relates to software systems is focused on taking some set or sub-set of code and "re-factoring" it, or otherwise, re-molding it to a more optimized state of existence and usefulness. Code that is not useful is either removed, replaced or refactored to be driven by test criteria, to be made smaller, faster and more reliable, as well as, other nefariously intelligent things such as reducing complexity, minimizing internal and external dependencies and so on. The changes are intended to be purposed and in small increments so as to preserve the integrity of the idea being refactored. It is not as if the base idea is wrong. Its current instantiation may simply require..."attention". You can reasonably characterize the behavior as the disciplined /art/ of engineering and one can absolutely do it wrong. However, to do it correctly may not be noticed by anyone other than the developer pair and change logs. The takeaway from this example is that there first must exist something that has a useful purpose, serves a greater good and merits optimization. Were there first nothing, refactoring nothing is not useful.

Now the idea of copy and paste is another conversation unto itself. To copy and paste an idea from one part of code to another without refactoring it to context and purpose may lead to failure. Already said quite well by the Agile Otter, --don't. Should I take code from one context and simply paste it into another context, it may actually be worse off on a number of levels than before such annihilation. Copyright or IP violations, stupid user issues, career compromise and so on. The conversation is actually deeper than this single-dimensional point. The simplest nugget around copy and paste problems may be this: what works in one context may not actually work when put into another context. In some way shape or form, it will require refactoring. And the takeaway for this particular para is that again, there must be a pre-existing state in order for copying and pasting anything to actually be a modification.

...but what if there was first nothing? Or, what if there was first a fractured instantiation of an idea?

If I first have a software program and I want to modify it, I have many decisions that I can make. Does the system work as it should already? Is it crafted to adapt/evolve or otherwise modify its own behavior as environment variables change or am I solely responsible for its evolution? Is there some part of the system that is just plain missing? Is there some part of the system that requires a nudge, nod or bump to move it from State A to State A++? Am I tired? Do I really give a rip?

The choice to copy and paste an idea from somewhere else into my existing system is a context-driven, relativistic choice. The choice to refactor my existing code or refactor that which I copied and pasted from someone else's hard work is also a context-driven, relativistic choice.

What if the data points I used to derive context are wrong? Is then my context wrong? Is it wrong locally or systemically? Is context relative to perception? Experience? How do I arrive at consistent context across ten different developers working on the same code base? How do I know that all ten developers are willing to invest the same level of effort, quality and usefulness into evolving said software system? What if just one of them, the one with the most influence and power, has it wrong?

Are we talking about a software system and team? Or are we discussing culture? Or are they the same? Is this the Matrix?

What if a culture has no identity? What if it has no discernible identity? What is the society itself cannot agree on one stronger cultural element over another OR it cannot agree on the synthesis of multiples?

Do you cut and paste an identity from somewhere else? Or do you cut and paste elements of one culture and paste it into your own? What if you miss the context in which it first originated elsewhere making the cut and paste non-meaningful or even breaking something else that used to work? Sure the framework appears to be there, but does it do anything useful? Is it really anything of note if you didn't create it and it doesn't usefully fit into this context?

And what about refactoring what already exists? Sure copy and paste plus refactoring could be the ticket in some cases. Refactoring an entire society seems like trying to boil the ocean in a single motion. Doesn't make sense. What if we refactored one element of a society or even one gradient of one element? Atomic level may be too small. To manipulate a system without disrupting it, incremental adjustments are required. The inverse may also be a strategy but is outside the bounds of this soliloquy. (Hello, am I alone in here?)

Alas, but I'm as bored as you are with this conversation.

What if, and I'm just making this stuff up as I come off the high from two pots of tea and too much sugar... what if every single person kept every single commitment every single time? Refactoring, Ctrl-C/V and relativism then all have a place to exist thereafter. First there is a base, then there is an evolutionary history thereafter. Yes, yes, I agree; there is an evolutionary history even if there is no base, it just may not matter for any longer than it takes to flush the cache.

Drive-By Analysis Fakers

I've spent significant time in Harare, Zimbabwe looking over technology, governance, process, procedure, business optimization, staffing, skill-sets versus education versus experience, short/mid and long-term national planning and execution efficiency, and technology incubation and evolution. A lowest common denominator for any civilization is technology. It is a fortunate or unfortunate fact depending upon where you are on the adoption curve. One simply cannot scale effectivity without it. Aside from the obvious needs for optimization which occur in any government, corporation or co-located group of individuals, I've noticed one particular trend that I believe should die a grisly, bloody death...

Drive-by analysis.

I'm an American. I see people from all over the Earth coming to Zimbabwe and a horde of other surrounding countries to help. Giving the benefit of doubt, the relationships are intended to be symbiotic (since I believe pure altruism doesn't really exist). Portugal, China, America, United Kingdom, Germany, Netherlands, South Africa and so on. I also see multiple international organizations with Mission and Vision statements articulating "we help" from anywhere on the planet. All said countries and organizations are designed, implemented and purposed to foster an international community of relative equilibrium. A good and noble cause. My challenge with what I see is the underlying, unspoken arrogance of superiority that sneaks out here and again with people providing the help.

Given these views are my own and represent no other individuals, corporations, organizations or countries, let me tell you what I see and think please and thank you.

I see two prominent characteristics in "helpers" that I characterize as unhealthy and non-productive.

The first is "I'm from a first-world country and you're a third-world country, so you're stupid" attitude. I cannot tell you the number of conversations I've ended up sitting in on or otherwise enjoying where one person from the outside communicates (and displays through tone, elocution and body positioning) in one way or another that they have the knowledge and it should be implemented without question. It is personally understandable to experience frustration solving problems you've personally and professionally solved years or even decades ago. However, the intent of teaching is supposed to foster autonomous growth later. Autonomous growth requires confidence and confidence is stymied should learning be accompanied by ridicule or other de-constructive motivators.

Now in all fairness, everyone has an opinion including and definitely me given I'm writing out this commentary. And many opinions have truth in there somewhere. Opinions are important for developing more substantial thought and action and are a valuable part of social/intellectual maturation. Think. Argue. Re-think and so on. Teaching children to think critically and draw upon multiple experiences and/or data elements to infer a choice and direction is the gold upon which individual, societal and global evolution exists.

The sad part of the equation is that, buried inside the attitude and/or unhealthy behavior, there is in fact gold-laced knowledge that would be valuable to pass along, but it gets lost in the pink noise. Proper scientific behavior calls for the hypothesis and associative result set to be independently verifiable by any number of other professionals in the field in order to prove valid. If the expert in this equation is in fact an expert, inclusion of scientific principle, in addition to, context-driven application of an idea and solution would be present. Absent these characteristics my dear helper, it is a fair for your expertise and professionalism to be challenged whether you like it or not.

Of course those in political positions would consider scientific-based behavioral endeavor a luxury unavailable to them during dynamically occurring, multi-level international relations negotiations AND precluded most of the time based upon context-driven conditions of international policy and legislation. Consultants and 'helpers' within private organizations don't have that argument. "You're stupid" isn't a healthy attitude for anyone. It is a tough state of existence to be pulling someone off the ground and telling them they are stupid at the same time.

The second behavior I see is people who fly into the country, holler about this and that, then fly back home. Not everyone is really aware of the private-to-the-industry consulting tenet of, "If you come from far away and charge lots of money, you must be awesome." I am. It is not always true. Sometimes it is an absolute. (Can an absolute be "sometimes"?) Sometimes, this very valid tenet is exploited by fakes. I recommend the following: gig them for a three month contract, place explicit deliverable expectations on them every two weeks and see if they make it through the knothole. Three months is a long time for a fake. Six months is a killer.

It is true that teaching must follow the stages of: a) Tell, b) Show, c) Watch, d) Leave. It is a valid behavior. It works. However, many people are not willing to invest this amount of effort into change. It is tough. Period. Many people like to spend the amount of effort it takes to order a cheeseburger at a fast food restaurant, tell everyone they catered a lunch event, and call it a day. They are fakes. Talking to your kid only at bedtime doesn't make you a parent. Showing up for seven out of twenty legislative meetings doesn't make you a Senator. Flying to another country and telling people things are FUBAR and then flying back home doesn't make you helpful. It makes you part of the problem. Somehow that fact mysteriously doesn't make it into the marketing, advertisement and campaign trail reels though. Not really surprising though, is it?

My argument stems from a single point:

If we, anyone, want to be helpful to anyone else, it requires a time, effort and cost commitment. Sometimes it even requires sacrifice.

An automated EFT to a charity organization is indeed helpful. In fact it is most helpful if you don't want to know where the money is going and you never contact the organization to see how the progress is going. Organizations love blind givers. Order a cheeseburger, hand it to a homeless person and tell all your friends and family that you started an organization for the homeless. True help requires leadership by example, leadership from the front and very significantly, a time and effort commitment to be around for an extended period of time. If people are to learn from you, exemplify through words and actions those things you would like others to learn. Unfortunately, change doesn't happen over the weekend. It requires time. Given the rate of decay, maybe you should be handing out twinkies instead of cheeseburgers so that you can claim your sacrifice and investment has a five-year shelf-life.

If I've pissed you off by now you may now spend time dispelling the validity of my commentary. No worries, I'll see you on the other side of the board room table eventually. And if its not me, know that I'm spending time training other people to be real, transparent and effective. In addition to that, I'm helping them tune their BS meters to immediately recognize when fakes walk into the room, because whether this is universally known or not, fakes smell like that which they espouse.

Real leaders (if you're an international focused helper, you're also a leader) constantly evaluate their own effectiveness and value to the situation prior to, during and after the engagement in which they are constantly, purposefully and personally involved. Real leaders are obvious. Ironically, so are fakes.

When you walk into the room to help and to lead, do you smell? Hopefully, you're not the last one to know the answer.

Context, Baselines, Assumptions and Being Globally Competitive

I've been working in Harare, Zimbabwe for a couple of months now to bring what I have in my toolbox to new teams looking to learn leadership, software, Scrum, XP, business start up behaviors, competition and the like. Having worked in domestic and international companies of 800 up to 150,000 in various industries, budget sizes, project complexities and all that, I have a trick or two here and there to offer. How do you work in large and small teams? How do you deliver value? How do you implement continuous frameworks? How do you compete internationally? How do you even find out about your global competition? How do you manage geographically distributed teams? How do you prep for board meetings, venture capital conversations and meet with important people in fancy suits and so on? What is important legislation and policy and what is pork barrel fodder? When a suit and when a Def Leppard t-shirt? I've had the opportunity to learn from great people, work with great people and be part of great teams. I've also worked with wienies. Given the relatively young age of the software engineering industry in this country, there are important decisions the technology sector needs to make in order to become great or be considered innocuous and non-existent. To be a rockstar or a wienie is a decision people make, many times unknowingly.

Ironically, the hard decisions will not be 'fiber or not to fiber' or 'M$ versus Linux' (although there is really no decision here). The hard decisions will be to determine what type of industry, what type of business model, education and behaviors will be fostered in order to create an internationally competitive industry. Who are you? Why does the international community care? And what are you going to do about it? The devil is in the intangibles.

For example, a conversation harder than choosing your operating system includes understanding intangibles like the value of context. Context is understanding the backstory. The backstory is important if you really want to understand why Superman keeps saving the same girl, why the Hulk came into existence and scowls all of the time, why Jean Luc Picard does classical theatre, why beer and jelly donuts are popular with some people, why Queensryche has such interesting lyrical structure and why its cool if your guitar amp goes to "11".

Context gives you additional knowledge and insight into why something is the way it is and helps prevent you from jumping to conclusions without all the pertinent facts. Context helps you understand with greater depth and breadth of it all. Context also often has to be sought.

In another setting, an oft popular joke is asking someone if they know what assumptions really do (something about donkeys or the like). Ordinarily people agree that assumptions are dangerous. Assuming that this year's taxes will be like last year's can easily help you skip a couple of pertinent steps in the tax forms saving you money (or costing you more). Assuming that beef jerky in one country is basically beef jerky in all countries may be the difference between a healthy mind and one with holes in it. Assuming that all people value independent thought is naive. Assumptions are often, though not always, shortcuts to conclusions without the necessary time and thought to fully understand a person or situation. Assumptions kill, hamper or otherwise set us down the wrong path. Makes one wonder about politicians and legislation doesn't it? What about leaders in general?

And what about baselines? How do you ever know where you are if you don't know where you came from? For example, you've made an improvement to a house and someone asks you to prove that your change is actually an improvement. Can it be done without evidence of the pre-existing status? Is the improvement a fact or an opinion? If it is a fact, shouldn't it be self-evident? An organization asserts by their existence the lives of countless people are improved? Without a baseline of how things were prior to the existence of this organization, how can you know? Maybe its actually worse. Or what if someone suggests that this year we've had the most snowfall ever recorded in history and its also the first year we've recorded snowfall. Absent a notation on the pre-existing state, how can one evaluate the value of the change? One must know the origination point before change can be validated a positive or destructive. Another interesting anecdotal flank on legislation evolution isn't it?

Now, tie context, assumption and baselines together into a synthesized thesis. How do you successfully teach, mentor and coach in a different culture?

From what cultural context does this society originate? What is its associative context to its immediate and distant continental countries? What is the role of this country and its technology sector in terms of global competition? Do we have the same definitions of completion, success, failure, commitment, quality, competition and so on? Does cultural history impact the answers to these questions?

What assumptions do we make when interacting with a foreign country, its educational framework, technology sector, policy, legislation and leaders therein? Are they correct? Is what's important the same when comparing your home country to your present visited country? If 5NINES is important from whence you came, is it important to where you've traveled? What of QoS? Is the 'customer as king' a universal? Do all people believe ordered, simple OO architecture is important or will simple scripted plate of spaghetti be called a Matisse?

And baselines. To contribute suggests measurable change. Measurable change suggests understanding the base state. Unless you documented the base state, your value is built upon your personal impression. What was the base technology state of this country's tech sector? Who baselined the infrastructure prior to implied evolution? If we eliminate political commentary and media fodder, can one determine base state, change, change velocity, forecast and deviation? If you have a plan, good for you. Tell me why your plan is useful compared to your base state. Then prove you're evolving.

Visitors do not evolve countries; baseline members of countries evolve countries from baseline state.

Visitors can be nothing more than catalysts. Assuming that where you are today versus yesterday is a globally competitive skill-set that should be notable to everyone around you is a deadly assumption. Invite more visitors, invite more competition and insert yourself into more opportunities to have your arse beaten and you'll flush out whether today is truly an improvement over yesterday. And while it is important for visitors to take into consideration historical cultural context, it is even more critically important for baseline members of a country to recognize how their own personal context does or does not colour their world views when sizing themselves up as a global member and competitor.

Baselines. Assumptions. Context.

Ladies and Gentlemen I assert to you that the easiest way to address all three of these important gamesmanship elements is through the introduction of free-enterprise international and domestic business competition.

If you do not baseline yourself prior to evolution, getting beaten by a competitor will do it for you. If you have a list of assumptions you use, standing in a group of competitors will not only bring them to light for you and everyone else immediately, but force you to choose your next step forward accordingly. And if you are forced to consider the context of your product, service, competitive stature or value in relation to those with whom you should be privileged to stand beside in addition to market demand, you will evolve or be beaten.

Free-enterprise competition is the way forward. It will evolve the market with or without you. And for sure, it will purge everyone of three important facets of being a competitor... the need for baselines to evidentially prove success, the need for assumption elimination to dismiss oversight, and the need for context to ensure you have the right baseline from which to eliminate your assumptions and make a plan that works.

Most of the world is not afraid of competition. If you are a global competitor, prove it. The intangibles will beat you before your competitors will.

Centers of Excellence & Best Practices

I've had occasion to work for companies big and small and a common denominator in many of them gravitated towards having centers of excellence and best practice libraries, policies and the like. In every single case, I learned. In hindsight, in every single case, the entity and associative output became a holy place without regard for actual evolutionary learning. I've had fifteen years of software experience to reflect on these entities and concluded for myself that they are over-used, misunderstood delusions of security we put in place so that we don't have to manage the real problems in companies. Other than that, I think they are great.

Of course I can't be let off that easily, so I'll explain.

People constantly yearn for consistent, predictable, repeatable experiences.

When I have an omelet, I expect consistency in the egg, the contents, salt, pepper and hot sauce and/or salsa every single time. It follows that I may be interested in ensuring that I experience the expected result to such an extent that I put in place a method -- explicit contents, explicit place to get contents, explicit naming, explicit measurements, explicit timing, explicit order of events, and perhaps even a specified cook. After I've created this process and associative procedure, I then manage to it. Deviation from the procedure is a problem, so I spend time putting in place methods to discover deviation, methods to notify me of deviation, methods to correct deviation and maybe, if it occurs to me, methods to mitigate and prevent deviation. Later, I'll likely have metrics, create statistics and then call it a best practice. My Center of Excellence created this process and my best practices emerged after I had metrics and so forth. Ta-da. I'm a corporation. My mom would be so proud.

The problem we really seek to solve is consistency. A pursuit we often fail to see is the need for consistent evolution.

When I create an architecture group in a development organization, it may very well serve a very temporal purpose politically, technologically and socially. However, should I leave it in place for very long it isolates individuals and teams, creates misconceptions of inequality and special treatment amongst team members, and creates an us:them assembly line conflict where one group allegedly does the thinking while another group does the grunt work thereafter. Later, the grunts may believe the architect is something to aspire to while the architect may believe grunts are non-respectable architect wannabes. Unhealthy.

Another example is having a particular group of people set aside to define methods of quality for the entire corporation. Whether they are experienced in the areas for which they create a process and procedure of quality or not is less relevant than the fact that they are not actually doing the work. So, someone who may have previous experience, maybe has performed fifty interviews of workers or just thinks they are super-smart, gets set aside in a special group of people to define the processes and procedures of excellence that will allegedly render excellence. Then line staff and management will need to be trained in said processes and procedures and then measured against them. This sets us up for a variation on a theme suggesting,

The beatings will continue until output matches our {contrived} standards of excellence.

It never ends because reality never matches ideals especially when more than one person is involved. To have a baseline is necessary. To devolve forward progressing behaviors back down to the baseline is a failure to value human aptitude.

It is far easier for managers to put up a fence and say, "Stay in there" than it is to lead by example, especially if the manager doesn't actually know how to do the work, let alone lead it by example.

I could continue. However, I'd rather focus on what the constant pursuit of excellence really looks like in a healthy team and environment. We do not need a group of people set aside to go Mensa on a problem, create a document and then employ project managers to police the line staff against it. We need an environment that fosters team-centered autonomous evolution. It is a very simple formula for some people, and a nasty medicine for others.

First, have a baseline. In order to evolve, there needs to be evolution from a point in time, position or state. Else, how can one know where you are in relation to where you started?

Second, demand the baseline to be destroyed due to evolutionary change. Not because the baseline is poor, but rather because the baseline is nothing more than a baseline.

Yes, there can be predictable, repeatable behaviors such as continuous integration, test, inspection and deployment. Yes, there can be canned iteration patterns, stand-ups, sit-downs, planning meetings, demos and reviews. Yes, it can be XP, Kanban, Lean and Scrum as the baseline.

Just recognize that constant improvement and evolution is the goal, not the by-product. Additionally recognize and accept that your golden baseline was never really golden.

Having a center of excellence implies someone else will do the thinking for me and alleviates the need for me to think.

I don't want a team of drones, I want wily, independent thinkers who challenge me every day.

Having a set of best practices suggests that we've defined end-state and I do not need to improve or pursue improvement any further than the best practice itself.

I do not want a team of line-followers, I want a team of people who challenge yesterday's assumptions, validate them today, and destroy them tomorrow.

Were I a harsh, critical sort, I'd say: "If you are a lazy manager, put in place a center of excellence, have them draw up best practices, employ project managers to police the organization against these practices, and sleep at night believing you are worth your salary." That's only if I were a harsh, critical sort of course.

If you want to build a rocket and go to the moon, have your team tell you every single day why they are better today than they were yesterday and how they'll be better tomorrow than imagined today. Ask them to keep track of their evolution across defined increments of time so you can all see the evolution. Some people call this an iteration review; some, lessons learned. Its really just evolution from baseline.

A team of continually evolving, wily independent thinkers will always beat center of excellence and best practice flunkies. Always. You just have to decide what you value the most -- the baseline or the evolution.