Technology Architecture & Projects

Happy Thanksgiving!

We celebrate Thanksgiving in the US tomorrow, and I'd like to wish my US readership a very happy holiday season!

Bob

Reminder: Carnival of Enterprise Architecture #13 Coming December 2, 2008

A friendly reminder that the 13th Carnival of Enterprise Architecture that I host through Blog Carnival is coming up on December 2, 2008, with submissions due by December 1, 2008. If you have an EA- or IT-related post that you'd like featured through the Carnival, you can submit the Permalink URL and related information here.

This is a very easy and effective way for EA and IT bloggers to get their messages across to a wider audience, and I hope that EA and IT bloggers will consider submitting their best pieces to the Carnival.

A few pointers for article submissions to the carnival:

* Spam, which includes pitches for commercial software or services, content spam, and off-topic material will be not be published.

* Feel free to nominate blog posts of others for the Carnival, but make sure to identify the author!

* Material posted in previous editions of the Carnival will not be re-published.

Again, the deadline for submissions is December 1, 2008, and the carnival will be published on December 2, 2008. I look forward to your contributions!

A friendly reminder that the 13th Carnival of Enterprise Architecture that I host through Blog Carnival is coming up on December 2, 2008, with submissions due by December 1, 2008. If you have an EA- or IT-related post that you'd like featured through the Carnival, you can submit the Permalink URL and related information here.

This is a very easy and effective way for EA and IT bloggers to get their messages across to a wider audience, and I hope that EA and IT bloggers will consider submitting their best pieces to the Carnival.

A few pointers for article submissions to the carnival:

* Spam, which includes pitches for commercial software or services, content spam, and off-topic material will be not be published.

* Feel free to nominate blog posts of others for the Carnival, but make sure to identify the author!

* Material posted in previous editions of the Carnival will not be re-published.

Again, the deadline for submissions is December 1, 2008, and the carnival will be published on December 2, 2008. I look forward to your contributions!

The Most Critical P-Word Of All

Nick Malik opines that measuring customer/sponsor/stakeholder behavior on projects should allow more of them to succeed. Nice thoughts, but I don't think it will fly, at least not in a lot of organizations.

Why? We focus primarily on what I call P-words: People, Process, Projects, Programs...and yet, there is one P-word missing; and it's the one that trumps all of the others almost every time:

Politics.

While Nick looks at projects as a partnership between business and IT - which it should be - it more often isn't, and the model most frequently used is the customer-contractor model. The business "hires" IT to develop systems and manage projects just like people hire general contractors to build or renovate their homes.When and if things on the project go awry, whether caused by the customer's actions or not, the contractor is much more likely to be blamed, take the fall and suffer the consequences - whatever those are.

Other project situations that may become politically-charged are when there are opposing forces/viewpoints against the project from other powerful people in the organization - including non-sponsor stakeholders that have competing interests or don't want things to 'change' in the manner in which they operate their portions of the organization. You can try and 'measure' that behavior all you'd like, but in the end, it won't much matter because a political crusade is being waged, not some rational discourse that leads to logical, obvious, and optimized conclusions and action.

Nick asks, "The project scorecard can be used to demonstrate that the right behaviors are happening on both sides.  After all, if a project fails because the business sponsor was unwilling to buy in to the approach, or wouldn't sign off on the interface design, or because the business users wouldn't participate in the test process, why should the IT team take the rap for missing the dates or overruns in cost?"

Because in the culture of a number of organizations, IT always takes the rap for project budget overruns and missed dates, whether it was responsible for them or not. That's largely the result of politics at work, not process or maintaining scorecards on unhealthy behaviors on the part of project sponsors and business stakeholders. Granted, sponsors and stakeholders who develop track records for sponsoring projects that repeatedly fail or cost too much often fall on their swords - eventually - but it usually takes more than one discrete project failure to have that happen. Often it takes several and in some cases, it never happens at all.

The best one can do in these types of situations is the following:

1. Perform the appropriate level of risk management on and in all phases of the project - or in every iteration if it's an Agile effort.
2. All risks should be communicated to the business, not only the consequences of the risk events, but what the remedies (if any) will be.
3. If risks are triggered for any reason, document it. Share it with sponsors and major stakeholders. If you encounter resistance or objection along the lines that Nick described above, there are reasons for those attitudes/behaviors (whether rational or not), and you must find out what those are and hope there are remedies short of project failure/cancellation.
4. Deal appropriately with the consequences of customer-triggered risk events. Business sponsors certainly have managers looking over their shoulders, but going over a sponsor's head with 'scorecards' and 'metrics' may backfire on you huge. Do that repeatedly, and let me put it this way: it's the wrong time in economic history to be unemployed.
5. Project managers must have an intimate business relationship with business sponsors and major stakeholders. There must be trust developed or already present on both sides, and when there is, that's a prime reason why successful project managers make the statements that Nick cites in his post about their sponsors. In such cases, there is no need to document business sponsor behavior on a 'scorecard.'

Projects are a lot like life - scorecards are useful for some things, but relationships matter far more in the end.

Is The Call For A Federal CIO/CTO "Reinventing Government" By Another Name?

I spent some time recently going a bit deeper into President-elect Obama's call for a Federal-level Chief Technology Officer and came to the realization that it, and the various responses by individuals and groups, strongly resemble major parts of the Clinton Administration's (specifically then-Vice President Al Gore) attempt to "Reinvent Government" (and, to be completely fair historically and politically, the 1994 Republican Party "Contract with America" that helped them sweep congressional seats wasn't any better - or worse.) History shows that while the effort led to some marginal improvements here-and-there and saved a few billion dollars that were quickly spent on something else, it really didn't accomplish very much and the results were nowhere near what the political speeches trumpeted to the electorate in that day.

As I googled and found various documents, articles, and other artifacts from those efforts, I came across an article written in February, 1995 by the late management guru Peter Drucker in The Atlantic Monthly. Dr. Drucker posits at length why "reforms" like this don't usually work, and proposed how they could do so. As with almost all of his writings, this one is well worth reading and really resonated with me.

In light of the Obama CTO proposal and Friday's (11/14/2008) news that there is little or no government oversight around the $700 billion of our money being dished out to bail out banks and insurers, Dr. Drucker's commentary, although made years ago, takes on a greater sense of urgency to reform and rightsize the federal government. Some highlights:

"There has been no lack of publicity about the Gore initiative since. Press release after press release has announced the reinvention of yet another agency or program; big conferences, one chaired by the President himself, have been convened, and any number of TV appearances made. Of all the domestic programs of the Clinton Administration, this is one of the few in which there actually have been results and not just speeches. Yet neither the public nor the media have shown much interest.

...There are good reasons for this. In any institution other than the federal government, the changes being trumpeted as reinventions would not even be announced, except perhaps on the bulletin board in the hallway. They are the kinds of things that a hospital expects floor nurses to do on their own; that a bank expects branch managers to do on their own; that even a poorly run manufacturer expects supervisors to do on their own--without getting much praise, let alone any extra rewards."

On proposals to "save money" that have no real effect, particularly to taxpayers and constituents:

'Even if all of these proposals were to be enacted, the results would be trivial. The proposed Agriculture Department saving of $3.6 billion over five years works out to about $720 million a year--or around one percent of the annual department budget of almost $70 billion. A saving of $12.5 billion looks like a lot of money. But over two years the federal government spends $3 trillion. An annual saving of $6 billion -and this is many times more than Congress is likely to accept--would thus be a cut of no more than two tenths of one percent of the budget. Surely the only way to describe the results of Gore's efforts so far is with the old Latin tag "The mountains convulsed in labor only to give birth to a ridiculous, teensy-weensy Mouse." '

The commentary above also reminds us that lobbyists, special-interest groups, and Congress always view the lack of budget growth as a "cut" in funding. To actually lower or terminate spending would be akin to heresy, and the 'savings' Dr. Drucker indicates above (in mid-1990s dollars) are minuscule and don't matter much in the end given the total amount of spending.

Dr. Drucker then goes further as to why the government must restructure:

'Any organization, whether biological or social, needs to change its basic structure if it significantly changes its size. Any organization that doubles or triples in size needs to be restructured. Similarly, any organization, whether a business, a nonprofit, or a government agency, needs to rethink itself once it is more than forty or fifty years old. It has outgrown its policies and its rules of behavior. If it continues in its old ways, it becomes ungovernable, unmanageable, uncontrollable.

The civilian part of the U.S. government has outgrown its size and outlived its policies. It is now far larger than it was during the Eisenhower Administration. Its structure, its policies, and its rules for doing government business and for managing people go back even further than that. They were first developed under William McKinley after 1896, and were pretty much completed under Herbert Hoover from 1929 to 1933.'

So, a new Federal CIO/CTO is going to come in, specify a load of technology to 'correct' all of this ancient and bloated organizational and process infrastructure, and declare victory? How many of us still follow very-explicit business processes from 1933? Or 1988, for that matter? Yes, there are some, but very few. In this particular case, the 'old-way' of government going about its business is the rule, not the exception. How is an infusion of 21st-Century technology supposed to improve or enhance business processes originally made in the 19th and early-20th century if the processes themselves aren't changed?

For those that want to play the 'blame-game' and lay this dilemma all at the feet of specific partisan or ideological interests:

'In fact there is no point in blaming this or that President for the total disarray of our government today. It is the fault neither of the Democrats nor of the Republicans. Government has outgrown the structure, the policies, and the rules designed for it and still in use.'

Dr. Drucker then wisely provides a roadmap for what organizations (not just government) should (and should not) do when confronting these issues:

'The first reaction in a situation of disarray is always to do what Vice President Gore and his associates are now doing--patching. It always fails. The next step is to rush into downsizing. Management picks up a meat-ax and lays about itself indiscriminately. This is what the Republicans and (as of last December) President Clinton now promise. In the past fifteen years one big American company after another has done this--among them IBM, Sears, and GM. Each first announced that laying off 10,000 or 20,000 or even 50,000 people would lead to an immediate turnaround. A year later there had, of course, been no turnaround, and the company laid off another 10,000 or 20,000 or 50,000--again without results. In many if not most cases, downsizing has turned out to be something that surgeons for centuries have warned against: "amputation before diagnosis." The result is always a casualty.

But there have been a few organizations--some large companies (GE, for instance) and a few large hospitals (Beth Israel in Boston, for instance)--that, without fanfare, did turn themselves around, by rethinking themselves. They did not start out by downsizing. In fact, they knew that the way to get control of costs is not to start by reducing expenditures but to identify the activities that are productive, that should be strengthened, promoted, and expanded. Every agency, every policy, every program, every activity, should be confronted with these questions: "What is your mission?" "Is it still the right mission?" "Is it still worth doing?" "If we were not already doing this, would we now go into it?" This questioning has been done often enough in all kinds of organizations--businesses, hospitals, churches, and even local governments--that we know it works.

The overall answer is almost never "This is fine as it stands; let's keep on." But in some--indeed, a good many--areas the answer to the last question is "Yes, we would go into this again, but with some changes. We have learned a few things." '

If the incoming Obama administration is serious about 'real change' in the federal government, they're going to need to confront reality along the lines of Dr. Drucker's advice above. So will Congress, if they can possibly get past the lobbyists and special-interest groups - a tall order but it may be possible. The answer is definitely not hiring someone as a pseudo-overlord CIO/CTO to throw technology at the problems and declare victory - that's akin to "patching over the problems" and always fails in the end.

On the other hand, 'real change' will eventually be forced upon us by huge, swirling budget deficits and immense, unsustainable government debt - and that time will come much sooner than most people think. We have an opportunity now to examine, diagnose, address, and correct these problems in a rational, sensible manner.

Or have it mandated to us by the rest of the world, which would most likely result in 'amputations without diagnosis,' and that game has no winners.

Proposed Federal Uber-CTO: It Isn't About The Technology

Disclaimer: I have consulted with various US federal government and state agencies in the past, and the views expressed herein are mine alone, and not those of the US or any state government agency.

President-elect Obama has proposed the appointment of a Federal Chief Technology Officer to oversee and overhaul federal IT operations - bringing US government IT into the 21st century with updated technologies, transparency, connectivity, etc. etc.

A great number of industry pundits and bloggers have jumped on the bandwagon with many suggestions that not only encompass what to do, but who could be qualified to do it - Bill Gates, Vint Cerf, Jeff Bezos, etc.

Todd Biske has a number of thoughtful suggestions about what a Fed CTO might accomplish, and my commentary is going to be a riff on his views, with a bit of a difference: I'm positing that a Fed CTO will be rendered largely helpless and ineffective unless various federal laws and regulations that drive and directly affect government IT are overhauled - including broad and mandatory standardization. Unless this happens, and fairly quickly, no amount of technology or infrastructure is going to turn this bloated boat around anytime soon.

The federal government operates under myriad rules and regulations that are often specifically tailored to agency goals and operations. In addition to US statutes passed by Congress and signed into law by presidents, we have the Code of Federal Regulations (CFR), Executive Orders, the decisions of various federal judges/panels, the Tax Code (part of statute, but a monster in its own right), agency/commission orders, procurement rules, OMB compliance mandates, rules, regulation, more rules, and on and on and on....

And I haven't mentioned, at least directly, the Clinger-Cohen Act (a.k.a. The Information Technology Reform Act of 1996) yet. That one mandated CIOs for all government agencies in addition to creation and 'mandatory' utilization of the Federal Enterprise Architecture Framework (FEAF) - which is essentially a Zachman framework adapted specifically for the federal government. The positive impact that Clinger-Cohen has had on government IT operations is highly debatable, and needs to be revisited and perhaps overhauled as well.

Confused enough yet? I don't know anyone that wouldn't be. It's a big mess, and it can be untangled, but it will take time, a great deal of effort, and of course, money...but that's what the Federal Reserve's printing presses are for - given that they're currently rolling along smartly for banks, insurers, credit card companies, and perhaps the automobile industry.

One of the fundamental challenges a Fed CTO faces is that most government agencies are very insular when compared against their sister agencies - they operate their piece of the government largely in a vacuum, and that's primarily due to all of the specific laws and regulations that they must honor and account for. A further conundrum is that a great deal of these laws and regulations are specific to an agency, and not the others. It's no surprise then, that agency processes/procedures, and thus, their IT, mirror this specificity and complexity. 

Then there is the issue of procurement. Suffice it to say that complexity and obfuscation rear their respective ugly heads here also, and needs to be overhauled. The focus on procurement issues is not just protecting the taxpayer from getting ripped off (which they often are anyway) but that the government derives value from the purchases - immediately and on-going. This would suggest that procurement needs to be streamlined, incremental, much more nimble to the market and emerging useful technology, and swing away from 'big-bang" projects/deployments that take years, cost much, and often fail.

Lastly, there are the issues of us, the people of this great land. We want transparancy, but do not violate our privacy. We want cost-effectiveness, but responsive and supportive agency functions, when we desire and need it. We value security, not just of the homeland, but of ourselves and our individual histories as represented by the data that the government specifically collects about us. 

What the new federal CTO faces is not just a 'technology' or IT problem, nor can it be solved simply by some name-brand IT whiz throwing interoperable, SOA-infused, Web/Enterprise 2.0 technologies at it. We have fundamental problems with the enormous bureaucracy that we have created over the years, and that has to be changed and optimized first before the technology comes in, because just throwing technology at the problem is not going to work.

Finally, I have a viable candidate for the CTO position, even though he is not as well known as some of the heavyweights bandied about by IT pundits and bloggers...how about this guy? I think he'd fit the position well.

Discipline, not Dogma

I received a few interesting comments to my "Bastardization of Agile" post, in particular this one from Pawel Brodzinski:

'While I agree with most of your points I strongly disagree with that one:
"Picking what parts of Scrum or XP are appealing to the PM, Scrum Master, or product owner, and ignoring the rest or superimposing waterfall as related above. Disaster often lurks right around the corner."

Actually picking what parts of Scrum/XP/any other nice methodology suits your process fine and applying only those parts is wise. If one of my projects would benefit from stand-ups why not to start them even if we don't keep 2-week iterations? If I find (sic) alue in short iterations while I don't have designated scrum master what keeps me from implementing it?

My goal isn't to be agile or have pure-agile processes in software development. My goal is to improve my processes. You can always do it as they do it in the books - 100% implementation of some methodology - and it should work. Unfortunately it's quite an effort to go this way. On the other hand you can choose wisely different techniques from different methodologies and craft your own software development and project management process. Sure, I won't call it agile but as far as I can call it good I don't care.'

Therein lies the problem: in organizations that are very new to and/or inexperienced with Agile methods, picking and choosing usually isn't good, as I related in my post. If it were, I would have no stories to relate and nothing to write about...

The point of my post isn't about dogma, it's about discipline. The problems I related occurred primarily due to two factors:

• Inexperience with the methods used
• Advancement of specific political agendas and/or weak overall management

This goes against Pawel's assertion of "choosing wisely" from different techniques - because of inexperience, grasping for silver bullets, or competing political agendas cause substantial project risk to be (perhaps unwittingly) introduced or perpetuated regardless of original intent.

In my opinion, the better move would be to manage a few projects "following the recipe" with whatever 'new' methodology - Agile or non-Agile - the organization wishes to embrace to gain valuable experience with the selected methods. And, staying the course through project completion in order to evaluate how well the methods worked - and will work in the future. That's the point of retrospectives, lessons-learned meetings, and the old, somewhat politically incorrect term "post-mortem" - do the project following the roadmap, keep/optimize what works, and drop or replace what doesn't. 

The only project managers that can do what Pawel suggests successfully are those that have substantial and real-world experience in the methods under consideration. Those that don't have such experience are limited to what they read in the books and blogs or hear from others second-hand - making critical project choices from that data or opinions alone.  The risk of major time/cost/scope problems increases when approaches are combined without thought or realization about the implications, or worse, as my post describes, are executed poorly because of a lack of discipline, not dogma.

Dogmatic approaches to anything never served anyone well - but lack of discipline in approach has ramifications that are most often just as bad.

My Uncle, The Blogger

My uncle Jim Fraser publishes The Energy Blog. I didn't know that he was blogging until we hooked up via LinkedIn a few months back. The last time I saw him was roughly 10 years ago when my aunt - his wife - passed away and I went to her funeral services in Massachusetts.

Anyway, since he makes his Sitemeter statistics available to the public, I clicked on it and here's what I found:

Wow! It just goes to show that when you blog on a very popular topic, the hits just keep on coming...:) Jim, now retired, was educated and worked as a mechanical and process engineer in energy-related industries. His commentary on the critical issues of energy are astute and well-worth your time, even if you are an IT geek like me...:)

It's also interesting to note that after he'd taken ill and stopped posting for a significant period of time, the blog was still generating tons of traffic. Which goes to show that if you have something to say that resonates with a diverse set of folks, they will come.

Keep up the excellent work Jim!  And best regards from your nephew...:)

The Bastardization of Agile

It's always easy to tell when something is resonating within organizations - and Agile is now firmly in that camp based on my experiences over the past two years. There is a tremendous amount of interest in Agile methods and many organizations are taking their first or second steps with it. On the surface, this looks great, but some of my experiences have led me to believe that Agile is thought of not as a different, solid approach to software design and development, but more (as I originally feared) as a silver bullet, completely misunderstood, or license-to-hack with little or no accountability for outcomes.

Herewith are a number of 'incidents' that I've recently observed or participated in:

• Regular loss-of-control-and-context in standup meetings, which at times make them drag on for hours. Scrum masters and PMs/facilitators must be vigilant in staying to the script, and taking issues off-line when necessary - and it very often is necessary. The result of not doing so is completely wasting uninvolved team members' time. Think of it this way: if standups are routinely going for an hour instead of 15 minutes, usually for one team member's issues, you are wasting 45 minutes of other people's time X the number of uninvolved team members. If this occurs on a daily or near-daily basis, the amount of wasted time is huge. And, since you're operating under iteration and timeboxing constraints, wasting team members' time like this will cause iteration goals to be missed repeatedly, and perhaps kill your project. Take very-specific issues brought up in standup that don't involve the entire team OFFLINE!
• "We're going to 'organizationalize' Agile." Which translated means "we're going to superimpose our culture and previous practices into whatever Agile methods (or parts) that we've selected. Translated further, this means that what will be superimposed is a lot of politics and waterfall/SDLC when Agile doesn't jibe with the existing organizational scheme - bad, bad move. Every time I've seen this happen, the projects involved are in trouble, and some have failed outright
• Picking what parts of Scrum or XP are appealing to the PM, Scrum Master, or product owner, and ignoring the rest or superimposing waterfall as related above. Disaster often lurks right around the corner.
• PMs, Scrum Masters, or Product/Business owners reverting to the term "Agile" when making decisions or taking action that are not, by any stretch, Agile. Examples: ignoring the self-directed team concept in Scrum by timeboxing work without consulting the team - which in reality is "make my date" project management - pick the date, work backwards to today, and tell the team when the work they are responsible for is due, regardless of team inputs, risks, or other schedules. Another example: assuming 100% dedicated team members and scheduling work when, in reality, the team members involved are not 100% dedicated because of other responsibilities they cannot get out of or pass to others. Finally, there are multiple product owners (ouch) that must come to consensus on stories and other direction - often quickly - and cannot or will not. The team is then left spinning their wheels waiting or worse, attempting to get some work completed by guessing what the stories/intent are - and the risk of being wrong is often high enough to cause a great deal of problems.

Based on these experiences and what I've been told by my students and colleagues, I get the strong impression that Agile is often used as an 'excuse' to advance a particular agenda. It's usually mentioned as a 'selling point' for projects - particularly to management and project sponsors/stakeholders to get projects approved and funded. It is also used for behaviors that are not Agile at all - when the PM who played the 'make my date' card on the project schedule was challenged in a meeting for not consulting with the people actually doing the work about the proposed dates, she replied, "Look, these are week-long iterations. It's Agile!" No, it isn't when the team isn't involved; it's 'make my date' and the consequent rectally-generated analysis that always follows.

My advice here remains the same as always: if you're going to do Agile development - do it. Completely and without compromise. When I am challenged in my Agile classes about modifying Scrum or XP or FDD to 'fit' some organizational political or budget scenario, my answer is always the same: "If you do that, then you are not doing Scrum/XP/FDD/etc. You are doing something, but not Agile methods."

And its always that "something" that leads organizations and groups who rationalize projects in this manner to fail.

 

Carnival of Enterprise Architecture #13 Coming December 2, 2008

The (Lucky) 13th Carnival of Enterprise Architecture that I host through Blog Carnival is coming up on December 2, 2008, with submissions due by December 1, 2008. If you have an EA- or IT-related post that you'd like featured through the Carnival, you can submit the Permalink URL and related information here.

This is a very easy and effective way for EA and IT bloggers to get their messages across to a wider audience, and I hope that EA and IT bloggers will consider submitting their best pieces to the Carnival. Please note that you do not have to be the author of the material to submit it, as long as it: a) meets the guidelines below; and b) honors the author's copyright and fair use guidelines.

As always, here are a few pointers for article submissions to the carnival:

* Off-topic material, sales pitches (direct or disguised) for products & services, and content spam will be not be published. Prior to every carnival episode, I delete a number of pieces of obvious spam, vendor ads, and off-topic material prior to publication - and it's a complete pain in the rear, believe me. Please don't waste your time or mine and thanks in advance.

* Feel free to nominate blog posts of others for the Carnival, but make sure to identify the author!

* Material posted in previous editions of the Carnival will not be re-published, regardless of who submitted it and when it was originally submitted.

Again, the deadline for submissions is December 1, 2008, and the carnival will be published on December 2, 2008. I look forward to all worthy contributions!

Modeling the Unthinkable

I've noticed a theme lately in a few books and current business periodicals about models - primarily financial and risk management in nature - not taking into account scenarios that have little or no chance of occurring - which at some point, do happen. Of course, since the models didn't account for such events, the organizations utilizing them promptly lost their shirts in the markets, went bust, got bailed out by the government, laid off thousands, ad nauseum.

This isn't exactly news - in the mid-1990s, the hedge-fund Long Term Capital Management (LTCM) made a fortune - for awhile - using computerized trading models to exploit pricing differences in various securities and derivatives. They also compounded those activities with a lot of financial leverage. Then in 1998, certain events that could 'never happen' conspired to bring them down like a house of cards: Russia defaulting on its debt, and subsequent market turbulence and credit markets seizing-up. The Federal Reserve hastily arranged a bailout by investment banks, and injected capital to stabilize the markets - which responded positively and led directly to...the dot-com boom and subsequent bust in 2000-2001.

Sound familiar, and like we're always doomed to repeat the past?

This is yet another lesson that a number of Black Swan scenarios (see "The Black Swan: The Impact of the Highly Improbable") must be thought out and accounted for in models. This isn't an easy task by any means, but it is necessary. The reason it isn't easy is that we must leave the comfort of the workaday, modestly-predictable existence that we see almost every day and become "Chicken Little" - assuming that "the sky is falling" and developing scenarios and responses to them that protect (to the extent possible) assertions and positions the main model espouses. Another conundrum is developing and selecting the "right" outliers and  scenarios to incorporate - again, this can get maddening, but if we don't do it, we're doomed to repeat the past.

What this means for enterprise, data, and software architects is that risk scenarios are acknowledged and to the extent possible accounted for, as models are developed and validated. It also means that models are critically reviewed by peers and stakeholders top-to-bottom. This should include vetting models against realistic scenarios that probably won't happen, but render cataclysmic outcomes if they do. Case in point that happens enough to mention: data architects developing logical and physical models that while well thought-out and designed, fail to take into account data volumetrics, flows, and the capacity of the production systems/databases to handle the load the models directly or indirectly propose. Then in test or even production, with the systems, network, and databases down or at best, crawling on their knees, it's a really bad time to think "damn, we should have simulated data flows and volumetrics to validate the data models!" Next!

The ultimate question in doing hypotheticals like this is how much risk you and your organization are willing to absorb. Ignoring that minute chance that a 'Black Swan' will arrive will usually work most of the time, but when it does arrive - and it eventually will - the results are never pretty. For anyone.