The presents are unwrapped, family has headed home, and the leftovers are almost gone. Once again, it’s time for ZapThink’s annual retrospective and predictions for the coming year. While it’s true that many pundits and prognosticators churn out their guesses for the year to come around this time, ZapThink takes the practice one step further: we actually review the previous year’s predictions and score ourselves on how well we did. Here then are our results from last year and our predictions for the year to come.

2011 Predictions: 2 ½ out of 3

I’m proudest of how well we did on our first prediction: one spectacular Cloud flameout. We so nailed this one, with Amazon Web Services well-publicized crash in April. I can’t help but say we told you so. We even went so far as to say “if you believe your Cloud provider is invulnerable, you’re fooling yourself.” Bottom line: expect for and plan for failure, especially in the Cloud.

We did well on our second prediction as well: that we’d run out of IPv4 addresses in 2011, and that the resulting shortage would lead to the growth of a secondary market in IP addresses. In fact, a black market for IP addresses has sprung up, in addition to the more above-board purchases, like the addresses Nortel sold to Microsoft. If the IPv4 shortage hasn’t impacted your organization yet, then 2012 might be the year you feel the pinch.

Our third prediction, however, is more of a work in progress. We predicted an “Enterprise Architecture is dead” story that would parallel the “SOA is dead” meme from 2009, as organizations move away from checklist architectures to more agile approaches that show better results. We’re giving ourselves 50% on this one, as no “EA is dead” meme has cropped up, or at least, no more in 2011 than in years previous. But speaking from personal experience, an increasing number of organizations are looking to move toward more agile, cost-effective architectural approaches, notably in the US Government with CIO Steven VanRoekel’s “Future First” initiative. As checklist architectures were endemic across the government, this shift is a good sign that our tax dollars are finally being spent wisely on architecture, at least here in the US.

Before we move on to our predictions for 2012, there’s one more prognostication to mention, from ZapThink’s predictions for 2008. We predicted that ZapThink would be acquired that year. We were off by three years, but we’re  now a happy part of Dovèl Technologies!

Predictions for 2012

Future First steals thunder from the Cloud – Our first prediction centers on the US Government, who is moving headlong into the Cloud. Dozens of agencies are taking the Cloud First initiative to heart, moving email, content management, and other key capabilities to the Cloud. Now, with FedRAMP ready to take off, agencies will be able to reduce the cost and complexity of moving to the Cloud.

But perhaps, not so much in 2012. We do predict FedRAMP will save billions of dollars of IT costs eventually, but there is simply too much politics involved to expect it to pay off substantially this coming year. In fact, we expect government adoption of the Cloud in 2012 to be more about politics than achieving real value. Instead, it will be a year of expanding the focus to Future First, as various federal departments and agencies, in conjunction with industry and academia, flesh out the combination of Agile, Lean, open source, and Cloud that VanRoekel has in mind. Cloud won’t go away, of course, as Cloud is an integral part of Future First. But the focus will gradually shift to Future First.

HTML 5 becomes the glue of the ZapThink 2020 vision – As the next major version of the Web’s central markup language, HTML 5 has been a long time in coming. In 2012, we predict it will hit a critical tipping point, as the next generation of Web markup, the replacement for Adobe Flash, and the common technology framework for Mobile app development. In addition, HTML 5’s Web Sockets technology that allows for full duplex tunneling via HTTP will open up new approaches for integrating capabilities in the context of rich, cross-platform user interface experiences.

As a result, HTML 5 will provide technology underpinnings, not only for mobile computing, but for ongoing improvements in technology across the board. After all, the user interface is where the value of technology manifests itself. We predict, therefore, that HTML 5 will impact multiple facets of enterprise IT, well beyond the user interface. Stay tuned for more thought leadership from ZapThink on this topic.

The rise of RESTful BPM – Just as SOA was misconstrued as an ESB-centric technology approach, people have confused REST with a way to construct APIs. However, that’s not what REST is about. REST is an architectural style for building hypermedia applications. And while you can think of a hypermedia application as a glorified Web site, it’s actually more than that: it’s a runtime workflow.

The idea of RESTful applications as runtime workflows is both simple and deeply powerful, as it entirely changes the way we might look at Business Process Management (BPM) tools. Traditional BPM tools are heavyweight, integration-centric tools that typically rely upon layers of infrastructure. Even lightweight BPM tools still rely upon centralized state engines. With REST, however, hypermedia become the engine of application state, freeing us from relying upon centralized state engines, instead allowing us to take full advantage of Cloud elasticity, as well as the inherent simplicity of REST.

Will people understand this shift in BPM approaches in 2012? Largely, no. But what will happen is that RESTful BPM will at least appear on the radar of organizations looking to approach process automation and optimization that leverages the Cloud without falling into the big vendor trap. What we do predict is more buzz about RESTful BPM, and at least one vendor bold enough to offer a truly RESTful BPM tool, instead of the non-RESTful attempts that we currently see from the vendors today. Are you a vendor who believes you offer a RESTful BPM tool that actually follows the REST constraints? We want to hear from you.

The ZapThink Take

ZapThink is pleased with the progress enterprise IT is making toward our ZapThink 2020 vision. The point to this vision was that individual trends in IT interrelate, and thus you shouldn’t separate any of them from the broader context of change within the organization. Whether it be SOA, Cloud Computing, mobile computing, or any of the five Supertrends, the only way to understand the message of ZapThink 2020 is to take them all together.

Our predictions for 2012 follow this pattern. The point to Future First is that it brings together Agile approaches with the Cloud and more. Our expectations for HTML 5 focus not on the user interface, but on how this standard will facilitate the ZapThink 2020 vision across enterprise IT. Likewise, RESTful BPM turns traditional integration—and even traditional SOA—on their heads, circling back to the World Wide Web as the central organizer for business at large.

Our predictions, therefore, are somewhat convoluted, not by accident, but by necessity. Pulling single strands out of the complex knot we call enterprise IT wouldn’t tell a useful story. Only by leaving the strands together and exploring how they interrelate can we gather useful insight into the change that faces us every day.

Read the entire release at http://www.prlog.org/11521158-architecting-the-cloud-at-cloud-expo-new-york-how-eas-should-think-about-cloud-computing.html.

Click to download: ArchitectingCloud-CloudExpo-062011-ZTP-0362.1

I ran a computer department for a small private school back in 1991. I remember rolling out our first Macintosh computers, the ones with one megabyte of memory and no hard drive (the hard drives were too expensive for us). I managed to get them up and running with no disk in the floppy drive, so that students could load and save their work to their own floppy.

This diskless approach was not particularly stable, however, and the computers would crash on a regular basis. As a result, my mantra was SAVE YOUR WORK! Expect your computer to crash, and plan accordingly!

Schoolkids being schoolkids, however, they frequently ignored my admonition. Sure enough, periodically one would come up to me with a tear in her eye. “Mr. Bloom! I just spent all period writing my English paper and the computer crashed! Please help!” But of course, there was nothing I could do at that point.

Two decades later, the computers are bigger, faster, and cheaper, we have the Internet and all it has done for us, and today we even have the Cloud. But in some ways nothing has changed. Failure is still unpredictable, yet it is around every corner. The core best practice, expect and plan for failure, is still as important as it was in the floppy days.

The Cloud: Built to Fail

It was actually my research into the causes of last month’s spectacular Amazon Cloud flameout that reminded me of my time in the school computer lab. One of the core architectural principles of Amazon’s Cloud—or any Cloud for that matter, public or private—is our old friend, expect and plan for failure. After all, each individual node in the Cloud, whether it be a server, hard drive, or piece of network equipment, consists of cheap commodity hardware. Each Cloud provider architects their Cloud environment so that any such piece of equipment—or even several pieces at once—can fail, and the environment should recover automatically.

In fact, fault tolerance and elasticity go hand in hand. Elasticity, which is the dynamic, automatic provisioning and deprovisioning of Cloud resources on demand, requires the same bootstrapping that fault tolerance calls for. Sometimes, the reason to bootstrap a box is to meet additional demand (elasticity) or to replace some other box that is having issues (fault tolerance). Essentially, when you need a new box, it boots and asks what it’s supposed to do, and then it finds and installs the appropriate resources to become the piece of equipment it needs to be.

Architecting for Failure

However, just because your Cloud provider architected their internal infrastructure to be elastic and fault tolerant doesn’t mean that your app will automatically inherit these traits once you move it to the Cloud. When an organization wants to run an application in the Cloud, it is important to architect the application to take advantage of the elasticity and fault tolerance the Cloud provides. Moving a big chunk of legacy spaghetti code into the Cloud is asking for trouble, as is trying to migrate a tightly coupled set of objects. Where you might have been able to get away with such design antipatterns for an in-house app, the Cloud forces you to clean up your act and deploy modular, loosely coupled apps that can take advantage of the inherently elastic, fault tolerant nature of the Cloud.

There is an important story here: the internal architecture of the Cloud is forcing organizations to rearchitect their apps, enabling them to take advantage of the Cloud, but as a welcome side effect, gives them better architected apps. But that’s not the only story.

The broader story is especially ironic. The irony, of course, is that a core Cloud best practice is to expect for and plan for failure—not only within the Cloud, but of the Cloud itself. The Cloud brokering we discussed in the last ZapFlash is no longer a “nice to have,” but rather a core architectural best practice. If you tell yourself that Cloud architectures are inherently fault tolerant, and therefore it’s sufficient to count on a single Cloud provider, you’re fooling yourself.

Architecting for the Cloud doesn’t mean sticking your app into the Cloud as though it were a black box. There’s far more to the story. On the one hand, it means rearchitecting your app to take advantage of the Cloud, and on the other hand, it means considering each Cloud provider instance as one element in your broader enterprise architecture. And if you want that enterprise architecture to be fault tolerant, avoid any single point of failure—even if that point if failure is the Cloud itself. Bottom line: SAVE YOUR WORK. I don’t want you coming up to me at the end of class because you lost your data. I won’t be able to do anything about your data, but I will be able to tell you I told you so!

Image source.

… nobody is doing enterprise architecture. The truth of this bold statement is quite obvious when you think about it. Where does enterprise architecture take place today? In enterprises, of course. That is, existing enterprises. And you don’t architect things that already exist. Architecture comes before you build something! Can you imagine hiring an architect after building a bridge or a building?

It’s a fine point. He goes on to say that instead, architects try to fix what’s broken using best practices and yadda yadda – it’s way more interesting to EAs, I’m sure. But here’s the rub: There are a slew of comments, some of which purport to agree then add a big “but” while others outright disagree.

Read the entire article at http://www.itbusinessedge.com/cm/blogs/lawson/enterprise-architecture-paying-off-at-del-monte/?cs=46661.

Read the entire release at http://www.prlog.org/11443635-cloud-computing-cloud-expo-new-york-dont-miss-last-chance-to-register-save.html.

In his new post Jason Bloomberg is asking a question “Why Nobody is Doing Enterprise Architecture ?” He notes that:

A solution architect architects a solution before that solution is implemented. A Java architect or a .NET architect does their work before the coders do theirs. You don’t build and then design, you design and then build… Enterprise architecture, on the other hand, always begins with an existing enterprise… The role of today’s enterprise architect is essentially to take the current enterprise and fix it. OK, maybe not the whole thing, but to make some kind of improvement to it. Go from today’s sorry state to some future nirvana state where things are better somehow.

Read the entire post at http://www.infoq.com/news/2011/04/EnterpriseArchitecture.

I’m sure it comes as no surprise that I belong to a number of enterprise architecture-related forums and discussion groups. Sometimes, however, I wonder if it’s worth the trouble. After a while, the babble coming from these groups begins to repeat itself, devolving into argument after argument on what enterprise architecture really is.

In our Licensed ZapThink Architect (LZA) course, we love to point out that the collective term for architect is an argument. As in a flock of seagulls, a pride of lions, or an argument of architects. Put enough architects together in a room, and sure enough, an argument ensues. Furthermore, architects love nothing more than to argue about the definitions of terms—since after all, definitions are simply a matter of convention. Bring up the question as to what “enterprise architecture” means, well, you might as well go home. No more work will be done today!

It doesn’t help matters that many techies have co-opted the term enterprise architecture to mean some kind of technology-centric architecture or other. Look up enterprise architect on a job board and chances are, four out of five positions that call themselves “enterprise architect” are entirely technology-focused. In spite of this confusion, if there’s one thing enterprise architects can agree on, it’s that enterprise architecture is not about technology. Sure, every enterprise these days has plenty of technology, but there’s more to the enterprise than its IT systems.

Unfortunately, there’s little else enterprise architects agree on. Some of them point to ontologies like the Zachman Framework, in the belief that if we could only define our terms well enough, we’d have an architecture. Others point to methodologies like TOGAF’s Architecture Development Method (ADM), figuring that if we follow the general best practice advice in the ADM, then at least we can call ourselves enterprise architects.

Hence, an argument of architects. If you’re an architect, you probably already disagree with something I’ve written. See? What did I tell you?

The problem is, neither Zachman nor TOGAF—or any other approach on the market, for that matter—is truly enterprise architecture. Why? Because nobody is doing enterprise architecture.

The truth of this bold statement is quite obvious when you think about it. Where does enterprise architecture take place today? In enterprises, of course. That is, existing enterprises. And you don’t architect things that already exist. Architecture comes before you build something!

Can you imagine hiring an architect after building a bridge or a building? I can hear that conversation now: “we built this bridge organically over time, and it has serious issues. So please architect it for us now.” Sorry, too late!

Most forms of technical architecture don’t fall into this trap. A solution architect architects a solution before that solution is implemented. A Java architect or a .NET architect does their work before the coders do theirs. You don’t build and then design, you design and then build. Even if you take an Agile, iterative approach, none of your iterations have build before design in them.

Enterprise architecture, on the other hand, always begins with an existing enterprise. And after working with hundreds of existing enterprises around the world, both private and public sector, I can attest to the fact that every single one of them is completely screwed up. You may think that your company or government organization has a monopoly on internal politics, empire building, irrational decision making, and incompetence, but I can assure you, you’re not alone.

Enter the enterprise architect. The role of today’s enterprise architect is essentially to take the current enterprise and fix it. OK, maybe not the whole thing, but to make some kind of improvement to it. Go from today’s sorry state to some future nirvana state where things are better somehow.

If you’re able to improve your enterprise, that’s wonderful. You’re providing real value to your organization. But you’re not doing architecture. Architecture isn’t about fixing things, it’s about establishing a best practice approach to designing things.

OK, so if nobody is doing enterprise architecture, then who actually architects enterprises, and what are they actually doing?

The answer: nobody. Enterprises aren’t architected at all. They are grown.

Every entrepreneur gets this fundamental point. When entrepreneurs first sit down to hammer out the business plan for a new venture, they would never dare to have the hubris to architect an organization large enough to be considered an enterprise. There are far too many unknowns. Instead, they establish a framework for growth. Plant the seeds. Water them. Do some weeding and fertilizing now and then. With a bit of luck, you’ll have a nice, healthy, growing enterprise on your hands a few years down the road. But chances are, it won’t look much like that original plan.

Does that mean there are no best practices for growing and nurturing a startup through all the twists and turns as it reaches the heights of enterprise-hood? Absolutely not. But most people don’t consider such best practices to fall into the category of architecture.

If you’ve been following ZapThink, you can probably guess what the difference is. “Traditional” enterprise architecture—that is, take your massively screwed organization and establish a best practice approach for improving it—follows a traditional systems approach: here’s the desired final state, so take certain actions to achieve that final state.

Growing a business, however, implies that there is no specific final state, just as there is no final state for a growing organism. An acorn knows it’s supposed to turn into an oak tree, but there’s no specific plan for the oak tree it will become. Rather, the DNA in the acorn provide the basic parameters for growth, and the rest is left up to emergence.

Such emergence is the defining characteristic of complex systems: systems with emergent properties of the system as a whole that aren’t properties of any part of the system. Just as growth of living organisms requires emergence, so too does the growth of organizations.

Perhaps it makes sense to call the establishment of best practices for emergence architecture. After all, if we can architect traditional systems, why can’t we architect complex ones? As a matter of fact, we do just that in our LZA course. If we have any hope of figuring out how to actually architect enterprises, after all, we’ll need to take a complex systems approach to enterprise architecture. It remains to be seen, however, if it’s possible to architect enterprises that way. Have an opinion on the matter? Let the arguments begin!

Image source: http://www.flickr.com/photos/digitalsextant/4835111700/

One of the primary reasons ZapThink decided to offer a formal credential for our Licensed ZapThink Architect (LZA) course was to address the demand in the marketplace for official, third-party recognition of architects’ knowledge and expertise. And we’re not alone: The Open Group’s TOGAF certification as well as the Enterprise Architecture (EA) certification from CAEAP also serve to meet this need, among others. The industry is on the right track. Clearly, without such vendor-independent certifications, there’s no hope that EA will earn its status as a profession. Unfortunately, however, certification is only the first step.

There are certain characteristics that differentiate formal professions from other careers. Physicians and lawyers must obtain certification, typically from a government-run or government-sponsored certification body. These professions have standards of practice and codes of conduct that Congress or other legislatures (or their global equivalents) pass into law. If a professional violates such practices or codes, they are guilty of malpractice, opening them up to lawsuits and potential loss of license. As a result, such professionals must purchase malpractice insurance to address the resulting liabilities.

In essence, what distinguishes a profession from other careers is the governmental regulation that protects customers from incompetents and charlatans. So, are we calling for governmental regulation of the EA profession? Not so fast.

The problem is that we are nowhere near ready to involve legislation in the EA profession. There would need to be broad agreement among EA practitioners as to what constituted proper, professional EA. Today, however, EAs cannot even agree on what EA is, let alone how best to conduct the practice of EA.

It’s as though we were asking what it would take to become a cardiologist, but nobody in the medical profession had made it past pre-med anatomy. Everybody is still arguing over what to call the various parts of the architecture, while discussions of how best to go about architecture are still quite broad and vague.

ZapThink discussed this problem in our Beginning of the End for Enterprise Architecture Frameworks ZapFlash, where we not only called for moving past EA frameworks, we also called for the industry to move beyond the few EA methodologies that are available, like the Architecture Development Method (ADM) that is part of TOGAF. While a step in the right direction, such methodologies lack sufficient detail and formality to provide the rigor required for professional licensure. In fact, The Open Group is the first to admit that the ADM is necessarily generic, and they call upon architects to extend and customize it for particular purposes.

If the medical professions took this approach, you’d never want to see a physician again. After all, patients would die if medical specialties were “necessarily generic,” and called upon physicians to “extend and customize” the formal methodologies that their profession calls for. Certainly, physicians must have the experience and courage to interpret the rules of their profession in the context of the needs of the patient. But the flexibility we expect from our medical professionals is a far cry from the inherent ambiguity and generality in the ADM or any other EA methodologies on the market.

You might argue that today’s enterprises are too varied and too heterogeneous for any such methodology to provide specific, verifiable guidelines for EA best practice. But that perspective doesn’t hold water either. After all, the human body is arguably more varied and heterogeneous than any large organization. The problem may simply be inadequate motivation. While human life is at stake in the case of the physician, what is at stake in the case of EA? The viability of the enterprise?

Perhaps, but probably not. Indeed, if poor EA clearly correlated to business failure then the marketplace would be louder in its demands for a formal EA profession. But business failure is too high a bar to set. Instead, poor or absent EA typically leads to disorganized organizations struggling under the burdens of bureaucracy, politics, and management inefficiency. Which enterprises have such afflictions? All of them.

It’s as though we’re in the Middle Ages. If you have a headache, head to your barber for some bloodletting. No scientific method, no real idea of how the body actually works, nothing but a bit of impromptu trial and error that gives our poor barber a hint that sometimes bloodletting helps with headaches. Without the underlying science, the formalized experimentation that leads to reasoned conclusions about cause and effect in complex systems, there’s no good reason to believe today’s EAs can achieve any greater level of professionalism than the Medieval barber.

The ZapThink Take

We don’t mean to insult the numerous EAs out there who endeavor to help their organizations deal with the change and complexity that all enterprises face. You’re doing the best you can with the tools you have. It’s not your fault your tools are still too primitive to establish EA as a formal profession. But look on the bright side: at least you don’t have to purchase malpractice insurance!

On the other hand, the challenges facing the EA profession present enormous opportunities, both for enterprises themselves as well as for the software vendors and consultants that are in business to help their enterprise customer base. If any large organization is able to improve upon their formal EA practices to the extent that they actually solve internal bureaucracy, politics, and inefficiency issues, they will be able to rise above their competition and achieve strategic value. Instead, the fact that all large organizations are in the same boat has led to complacency: why bother trying to solve such intractable problems if everybody has the same issues?

From the perspective of the vendors and consultants, there is a substantial prize that will go to the first service provider who can formalize EA best practices and provide the necessary tools for executing on those processes. Today’s EA tool marketplace is still serving the bloodletting barbers. Want to know how to move forward? Drop us a line.

What better way to ring in the New Year than ZapThink’s ninth annual Retrospective and Predictions ZapFlash? Ever since our first annual prediction ZapFlash on January 6, 2003, we have been reviewing our predictions for the previous year and then making new ones for the year to come. We also have a tradition here at ZapThink that no one gets to write the retrospective/predictions two years running, so no one gets to critique their own predictions. As a result, we never pull any punches. If our predictions were off, then we’re the first to admit it! In this spirit of irreverent camaraderie, therefore, let us review our predictions from one year ago.

Scorecard: Our 2009 Predictions for 2010

First, we predicted that open source SOA infrastructure will dominate. We called for  robust open source registry/repository, management, and governance offerings to roll out in 2010 in particular. ZapThink missed the boat on this one. Our thinking was that as the big vendors consolidated the market, enterprise customers would look for alternatives, and open source would be an increasingly appealing choice.

Instead, IBM and Oracle have largely sewn up the SOA infrastructure market. Forces of innovation and change have moved elsewhere. And in spite of the vendor-independent SOA drum ZapThink has beaten for a decade now, “SOA” for many organizations means “implementing a lot of software from IBM or Oracle that has SOA on the label.” Does that mean that vendor-independent approaches to achieving architecture-driven business agility are dead? Absolutely not. But we’re no longer calling it SOA.

Our second prediction: the Rich Internet Application (RIA) Market wars are over. Nailed this one. As we said last year, put a fork in it, it’s done.

Third, we predicted that we Cloud privacy and security issues would be put to rest. Our timing was off on this one. If anything, Cloud privacy and security issues are becoming increasingly central to many organizations’ move to the Cloud. We’ll eventually resolve these issues, but we didn’t do it in 2010. It’s unlikely they will be fully resolved in 2011 either.

Our Predictions for 2011

If you’ve been following ZapThink this past year, you know that we’ve laid out our ZapThink 2020 vision for the future of enterprise IT (including our free ZapThink 2020 poster). The question for this ZapFlash, therefore, are which of our ten-year predictions do we expect to take place in 2011? Here are the top three.

• One spectacular Cloud flameout – the entire Cloud Computing marketplace is reaching a fever pitch. The chum is in the water, and the vendors are hungry. Enterprise buyers are starting to invest in Cloud solutions. Investors are placing bets on Cloud hosting providers as well as infrastructure players. In the long term, Cloud has legs, no doubt. But in the short term? There will be a shakeout. Perhaps a large Cloud hosting provider will go belly up. Or maybe a WikiLeaks-style denial of service attack will take out a good chunk of the Cloud. Another possibility is a major Cloud security breach. One way or the other, Cloud will get a spanking this year.
• No more IP addresses – the IPv4 address space is running out, and we predict the last available IP addresses will be used up in 2011. The conventional wisdom is that this IP exhaustion will spur the adoption of IPv6. We agree—but that won’t happen in 2011 to any great extent. We predict, however, that the companies who lucked out in the early days and ended up with a Class A IP address range (each of which contains about 16 million addresses) will find a suddenly booming secondary market for those addresses. Standing to benefit: Ford Motor Company, Merck, Eli Lilly, DuPont, Halliburton, and the US Postal Service, among others. Not only is this issue a new battle for 2011, it’s an entirely new battleground.
• EA is Dead, Long Live EA – In early 2009 the story was that SOA was dead, and now it’s Enterprise Architecture’s turn. Perhaps the collapse of the Zachman Framework, or the increasing realization that EA certifications don’t correlate with EA competency, or the ubiquitous misperception that EA is about technology—all these trends are driving a nail in the coffin of Enterprise Architecture as it’s done today. But just as the “SOA is dead” story was actually one of refocusing on what was really important about SOA, the “EA is dead” story will lead to a rebirth of true Enterprise Architecture—best practices for architecting enterprises as complex systems in order to enable continuous business transformation. If your Enterprise Architects don’t actually spend their time architecting your enterprise, then what are they really doing?

The ZapThink Take

The common thread tying together our three predictions is the popping of bubbles of misconception. We love to fool ourselves, until such time as our illusions no longer hold water, and they burst. We may get wet, but we survive, and we move forward with a better understanding of the realities of the broader business environment.

If you believe your Cloud provider is invulnerable, you’re fooling yourself. If you believe the IPv4 exhaustion problem won’t affect you, yes, fooling yourself again. And if you believe that the CEO looks to the EA team for guidance because all your ontologies and standards and diagrams are exactly what the executive management team needs to be successful in 2011, you’re fooling yourself once more. 2011 is the year we get real, dispel the illusions that have impeded our progress, and tackle the real problems facing our organizations.