Showing posts with label Change. Show all posts
Showing posts with label Change. Show all posts

March 30, 2008

Speed is the Name of the Game and Enterprise Architecture

Enterprise architecture is a way to manage change and complexity. Enterprise architecture establishes the plan forward and governs the decision-making process, one IT investment at a time, and one business process improvement at a time, toward fulfillment of the target state.

However, change can happen slowly or quickly. The faster the change, assuming is it made with clarity of purpose, intent, and discipline, the better.

In the book, Never Fry Bacon in the Nude, by Stone Payton, the author states that “today’s (and tomorrow’s) market leaders recognize that speed may very well be the most consistent and durable source of competitive advantage.”

Why is speed so important to an organization?

In virtually every industry, the first to market enjoys as much as ten times (10x!) the profit of its nearest competitor…[further,] organizations that meet the most needs for the most people [measured in time] with an increasing ‘economy of motion’ dominate their respective markets.”

Speed is a cure for what ails an organization:

Like a powerful antibiotic, speed travels through the corporate bloodstream neutralizing the debilitating diseases of procrastination, apathy, confusion, malicious compliance, blame, and victim thinking.”

Stagnation is death for an organization or a person. The world is moving ahead and if we are not moving with it or better yet, ahead of it, we will fall behind (like the sick and feeble) and eventually die—as the theory of evolution and law of survival of the fittest prescribe.

Like the law of inertia, “objects [or organizations or people] at rest tend to stay at rest; objects in motion tend to stay in motion. Make no mistake about it—speed breeds speed, and the fast get faster.”

In enterprise architecture, we develop mechanisms to govern information technology. These mechanisms include architecture reviews of proposed new projects, products, and standards. The findings from these reviews get fed to the IT investment review board, who decides whether a project will be funded and how much. These governance mechanisms could be seen as detrimental to the organization’s ability to achieve change quickly.

Therefore, it is important that governance not be employed in the organization arbitrarily and that it not impose undue burden or slow the pace of innovation and transformation. Instead, IT governance should be applied so as to ensure clarity of purpose so that “good decisions are implemented with speed [to] produce good results.”

How does an organization move with alacrity?

  1. Structure—developing defined, repeatable, measureable processes with clearly defined roles and responsibilities, and standards for performance.
  2. Personal Accountability—“taking and expecting personal responsibility for corporate results.” And accepting failure to promote success—“many of today’s top performers have a surprisingly mediocre track record, with far more losses than wins to their credit.”
  3. Empathize—“when contemplating a new idea, they seek out potential resistors. Not to change their mind (not yet anyway), but to learn their mind.” Hearing and embracing opposing points of view actually can produce better decisions.
  4. Education—“fast, agile companies are Learning Organizations. They are relentless in collecting information, but more important—they organize and re-distribute knowledge more effectively than their slower, less nimble competitors.”
  5. Direction—“perhaps one of the most common characteristics among top performers—in every arena—is clarity of purpose.”

These disciplines for moving with speed tie directly to the goal of User-centric Enterprise Architecture, which is to provide useful and usable information products and governance services to the end-users to improve decision-making. EA provides structure through the architecture framework. It demands personal accountability through establishing the role of EA product ownership and the governance boards and setting up performance measures and criteria for selecting, controlling, and evaluating proposed new IT investments. User-centric EA empathizes with people through the human capital perspective of the architecture and through vetting enterprise information. EA provides a robust information asset base for the organization to make information easy to understand and readily available. And finally, EA sets direction for the organization by providing a clear roadmap, including a target architecture and transition plan.

What’s the biggest obstacle to speedy organizational change?

Probably the biggest speed trap for an organization or a person is fear of failure. But “even the simplest task, seemingly performed to perfection, is actually comprised of countless failures and one final correction.”

We cannot be afraid to change or to fail. We must be brave and steadfast in demanding ever-higher levels of excellence of ourselves and our organizations.

“If you want something to be scared of, then be deathly afraid of what will happen if you don’t capture the learning, make the corrections (and the connections), and go forward.”


Share/Save/Bookmark

March 14, 2008

Invention versus Innovation and Enterprise Architecture

User-centric Enterprise architecture is about producing valuable information products and governance services for the organization to enhance IT planning, governance and decision-making. There are elements of both invention and innovation in EA.

Invent“1. To produce or contrive (something previously unknown) by the use of ingenuity or imagination. 2. To make up; fabricate.”

Innovate“To begin or introduce (something new) for or as if for the first time.”

(TheFreeDictionary.com)

The definitions of invent and innovate are similar, but have important subtle differences.

  • Invent is to produce first which connotes a physical production or manufacture of an items, and secondarily to contrive or think up something imaginatively.
  • Innovate, however, is not producing or just thinking up something, but actually introducing it (for the first time), and in the process of introducing, there is an element of not only thinking up an idea or making it, but of actually bringing it to the marketplace to create value and reap benefit from it.

In User-centric EA, we both invent (think up and produce) products and services such as baseline and target architectures and transition plans as well as services to govern IT. However, we also innovate; we introduce the products and services, through effective marketing, communications, training, and leveraging their use to add value to the mission.

  • From a User-centric EA perspective, it is not enough just to put things out there (invent them)—like the “build it, and they will come” motto heard frequently during the period of “irrational exuberance” in the stock market and internet bubble of the early 21st century. Rather, we must innovate--constantly consider our users and build for them, to their requirements and make the EA of true value to them.

In BI Review Magazine, 3 December 2007, Thomas Koulopoulos presents “Don’t Invent, Innovate.”

Tom writes: “Myriad catalysts have suddenly created an ability to invent beyond our wildest dreams. Manufacturing is a global commodity…capital moves more efficiently to fund new ideas, micro markets can easily be targeted and fulfilled with well oiled supply chains. As a result we are surrounded by more useless inventions than at any other time in history. Affluence seems measured by the number of things we can accumulate and then drag to the nearest landfill…we confuse invention with innovation…too many people and organizations get wrapped up in the premise that quantity of invention is what drives progress. It’s not. Innovation is about imposing a discipline of value creation in an organization…Innovation is change with a purpose and a vision. Invention is simply change, the age-old battle between quantity and quality.”

In architecting the business and technical aspects of our enterprises, we need to keep in mind the distinction between inventing and innovation. Of course, we need to invent—we need to build idea and things--as humans, we need these “things” to survive. But also we need to innovate and ensure that what we invent is truly with purpose, vision, and is of value to the end-user.


Share/Save/Bookmark

March 4, 2008

John Zachman and Enterprise Architecture

In the Journal of Enterprise Architecture, February 2008, John Zachman, the father of EA, talks about core definitional elements of enterprise architecture.
  • Enterprise versus IT or Applications Architecture—”First Enterprise Architecture constitutes a paradigm shift and many people have not yet been inclined to make the mental, cultural, and behavioral adjustment to engineering and manufacturing the enterprise” and I love that phase—engineering the enterprise!

“Because…many of the skills required to the work of enterprise architecture are typically found in the Information Systems community, some people misconstrue the Framework intent as an Information Systems schema rather than its true intent as an ENTERPRISE schema.”

And not only is the Zachman Framework misconstrued as an Information Systems schema, but many people mistakenly confuse the whole EA with IT or applications architecture. But EA is not focused on IT or applications, but rather on the overall organization—the enterprise.

  • Lexicon—“As global communication and collaboration expands, there is an increasing requirement for semantic coherence. If people’s words do not mean the same thing, there is neither communication nor collaboration”—another good one, semantic coherence!

Without a lexicon with common definitions and standards for usage, we will not be talking to each other, but past each other.

Moreover, if we can’t even define EA elements in a common way, then how can we ever make them interoperable?

As Zachman says, “The underlying classification and components of architecture must be consistent for any interoperability (internal or external) to be effected.”

  • Classification, Taxonomy, and Ontology—“Enterprises are complex. Managing the knowledge base of the enterprise that is required for enterprise operation and change is complex. The key to managing complexity is classification.”

This is so true. We need to categorize and relate items to make sense of them. Moreover, I would say we need to roll this information up to what I call the profile level—the big picture, strategic view using information visualization—so that our executives and decision makers can quickly understand the information and come to a decision point.

“Humanity for seven thousand years has found no mechanism for accommodating complexity and change other than architecture,” says Zachman.

EA is the way to plan, manage, and measure change in our increasingly complex world. And if we don’t take control over our enterprises and their future destiny, then we will be controlled by them.


Share/Save/Bookmark

January 21, 2008

“Sacred Cows” and Enterprise Architecture

Enterprise architecture develops the organization’s baseline and target architecture and transition plan. EA is an endeavor of change and transformation from current state to future state. To achieve organizational change successfully, the “sacred cows” must be made change-ready.

In the book, Sacred Cows Make The Best Burgers, by Kriegel and Brandt, the authors explain that the greatest inhibitor to organizational change is people’s resistance—people are the gatekeepers of change and people are the enterprise’s most stubborn of sacred cows!

“Sacred Cow—An outmoded belief, assumption, practice, policy, system, or strategy generally invisible, that inhibits change and prevents responsiveness to new opportunities.”

What’s with this analogy to cows?

“Cows trample creative, innovative thinking. They inhibit quick response to change, and cost money and time. They roam everywhere…yet many organizations continue to worship their sacred cattle. They’re afraid to abandon what once made them successful, and they extract a heavy fine from those cow hunters who would ‘pasteur-ize’ them.”

What’s the imperative for change now?

“It’s hurricane season for American business. Winds of change are barreling in from all directions. Competition is tougher than ever and coming from places you least expected. The customer is more sophisticated and demanding. Technological change is incessant. Government regulations are tougher. And everyone is restructuring, reorganizing, reinventing, downsizing, outsourcing—all at ultrasonic pace.”

What are we doing about it?

“New programs, processes, and strategies have been introduced to help you keep ahead of these changes and eliminate sacred cows. In fact, they’re emerging almost as fast as the changes themselves…reengineering, total quality, virtual teams, ‘horizontal’ corporate structures…”

What are the results of these change efforts?

  • “Though it’s predicted that U.S corporations will spend $34 billion on reengineering, most efforts will flop.”
  • “Some statistics say seven out of ten reengineering initiatives fail.”
  • A McKinsey study found that “a majority of companies researched achieved less than a 5 percent change due to reengineering.”
  • Two-thirds of American managers think TQM has failed in their companies.”
  • “The number of applicants vying for the Malcolm Baldridge Award…has fallen since its peak year in 1991.”

In short, “The ’Q’ [quality] word has become cheap currency.”

Why do these change efforts fail?

  • “People’s resistance to change is ‘the most perplexing, annoying, distressing, and confusing part’ of reengineering.”
  • People resist change because “change is uncomfortable, unpredictable, and often seems unsafe. It’s fraught with uncertainty and always looks harder than it is….change brings us face-to-face with the unknown, and that evokes our worst imagined fears: We’ll be fired, humiliated, criticized. So we dig in our heels.”
  • “We’ve seen workers fight change for months and years because they didn’t understand it, were afraid of it, or didn’t see it being in their self interest. It’s naïve to assume that the bulk of the workforce will come around. Even when resistance seems to disappear, most often it’s just gone underground, and will resurface when you least expect it.”
  • “Management consultants who deal with companies in transition know that the ‘people’ part of change is critical. And that it is most often overlooked and undervalued.

The reason that three fourths of reengineering efforts fail…is that the focus of change is on work processes, new technology…and decentralized services rather than on the people who must implement change.”

From a User-centric EA perspective, this last point is critical. Enterprise architecture efforts, by definition, are focused on business, technology, and the alignment of the two. EA looks at business process improvement and reengineering and the introduction of new technologies to enable mission success. Traditionally, EA did not look at the human element—the people factor. The necessity of measuring people’s change readiness and assisting people in transitioning to new ways of doing things is one of the most important elements of any change initiative. As I’ve written previously, Human Capital is the missing performance reference model in the Federal Enterprise Architecture. All this points to the importance of transitioning from traditional EA to User-centric EA, where the end-users and stakeholders (i.e. people) are the most important element of the enterprise architecture. How would my kids phrase this, “in the end it’s not the business process or the technology, but the people, stupid!”

What happens if we don’t recognize the centrality of people to the change process?

Plain and simple, change efforts will continue to fail. Money and time will be wasted. Our competition will continue to gain on us and overtake us. Our organizations will be made obsolete by our own inattention to our most important asset—our people!


Share/Save/Bookmark

January 19, 2008

“Tear Down Those Silos!” and Enterprise Architecture

One of enterprise architecture’s “targets” is to transform the organization from being purely monolithic, functional-based silos (like operations, sales, marketing, finance, HR, legal, IT and so on) to an interoperable, cost-effective, mission and results-driven enterprise.

Matejka and Murphy in the book, Making Change Happen, clearly states that a “barrier to the successful implementation of any change is the division of the organization into silos. The grouping of the same or similar tasks (creating pockets of specialized knowledge) provides distinct opportunities for the disruption of the seamless implementation of new strategic initiatives.”

The authors ask “what is a silo and why does the term have such a negative connotation these days?

They then consult that Random House Dictionary for definitions of silo, as follows:

“A silo is ‘a tall, cylindrical structure in which grain is stored’ or ‘a sunken shelter for storing and launching missiles.’ Hmm. Very interesting. So a silo is a valuable protector of precious materials, but a single –purpose, single-use, fragmented, isolated, fairly impenetrable piece of organizational architecture.”

What makes organizational silos the enemy of change and transformation?

  • Professional jargon
  • Professional memberships
  • Turf and resource protection
  • Comfort zones…Discrimination”
“In a specialized professional department, is the employee’s real allegiance to the company or to the profession? The answer might surprise you. Many managers we have worked with would privately state that it is the profession.” This is why in functional- based siloed organizations, they cannot achieve the unity, integration, and synergy to make successful change happen."

To break down the silos and implement true “enterprise” architecture, you don’t need to get rid of the functions (since they serve a purpose and are important), you just need to use cross-functional teams, reward cross-functional performance and strategic thinking, broaden the perspective of functional silos by providing cross functional training and development.

Share/Save/Bookmark

January 14, 2008

The Sigmoid Curve and Enterprise Architecture


The Sigmoid Curve is critical for understanding the need, timing, and challenge for organization transformation efforts.

According to Charles Handy in the book “The Empty Raincoat,” The Sigmoid Curve, which is a S-shaped curve is the metaphor for the life-cycle of all things: from a product’s waxing and waning in popularity to the rise and fall of empires.

What can individuals or organizations do to survive beyond the Sigmoid Curve?

The secret of constant growth is to start a new Sigmoid Curve before the first one peters out.” And the right time to start the second curve is before reaching pinnacle of the first, so that there is time and resources to get the new curve off the ground (this is at point A). The challenge with starting a transformation effort or new Sigmoid Curve at point A is that “all messages coming through…are that everything is going to be fine, that it would be folly to change when the current recipes are working so well.” Unfortunately, if we wait until the sign of downturn and disaster is apparent (point B), then it is probably too late to make the leap to a new Sigmoid Curve, “leaders are discredited…resources are depleted,” and morale is damaged.

Another challenge with starting a new Sigmoid Curve and undertaking a transformation effort is that from point A to the pinnacle of the first Sigmoid Curve, it is “a time of great confusion. Two groups of people, or more, and two sets of ideas are competing for the future.”

“The discipline of the second curve requires that you always assume that you are near the peak of the first curve, at point A, and should therefore be starting to prepare a second curve. Organizations should assume that their present strategies will need to replaced within two to three years…it may well be that the assumption turns out to be wrong that the present trends can be prolonged longer…nothing has been lost. Only the exploratory phase of the second curve has been done. No major commitments will have been undertaken until the second curve overtakes the first.”

However, the importance of preparing for the second curve is that “it will have forced one to challenge the assumptions underlying the first curve and to devise some possible alternatives. It is tempting to think that the world has always been arranged the way it is and to delude ourselves that nothing will ever change. The discipline of the second curve keeps one skeptical, curious, and inventive.”

From a User-centric EA perspective, the first Sigmoid Curve is the current or baseline architecture and the second Sigmoid Curve is the target architecture. The Sigmoid Curves demonstrate to us the constant need to reinvent ourselves and our organizations—to transform from the as-is state to the to-be state. “Moving on requires a belief in…curvilinear logic, the conviction that the word and everything in it really is a Sigmoid Curve, that everything has its ups and then its downs, and that nothing last forever or was there forever.” This is the mandate for enterprise architecture; it is the way of constant vigilance, innovation, and transformation to survive to the next Sigmoid Curve of life.
Moreover, “the accelerating pace of change shrinks every Sigmoid Curve.”

Share/Save/Bookmark

January 12, 2008

The Marines and Enterprise Architecture

Traditionally, the Marines are known for their rapid, hit hard capabilities. They are a highly mobile force trained to transport quickly on naval vessels and literally “take the beachhead.” However, with the war in Iraq, the Marines have assumed a more non-offensive deployment posture in “conducting patrols.”.

The Wall Street Journal, 12-13 January 2008, provides an interview with the Commandant of the Marines, General James T. Conway about the need for “the Corps to preserve its agility and its speed.”

“It’s the future of the Corps not its past that dominates Gen. Conway’s thoughts…that in order to fight this war, his Corps could be transformed into just another ‘land army’; and if that should happen, that it would lost the flexibility and expeditionary culture that has made it a powerful military force. The corps was built originally to live aboard ships and wade ashore to confront emerging threats far from home. It has long prided itself in being ‘first to the fight’ relying on speed, agility, and tenacity to win battles. It’s a small, offensive outfit that has its own attack aircraft.” However, in Iraq, the Marines are performing in a “static environment where there is no forward movement” Additionally, there is a feared culture change taking place, the marines “losing their connection to the sea while fighting in the desert” over an extended period of time.

When we think about enterprise architecture, most people in IT think about technology planning and transformation. However, EA is about both the business and technology sides of the enterprise. Change, process reengineering, and retooling can take place in either or both domains (business and technology). In terms of the Marines, we have altered their business side of the enterprise architecture roadmap. We have radically changed their business/mission functions and activities. They have gone from service and alignment to the long term mission needs of this nation for a rapid, mobile, offensive fighting force to accommodate the short term needs for additional troops to stabilize and conduct counter-insurgency and peace-keeping operations in Iraq. Whether the business functional change ends up hurting the culture and offensive capabilities of the Marines remains to be seen. However, it does raise the interesting question of how organizations should react and change their functions and processes in reaction to short term needs versus keeping to their long term roadmap and core competencies.

Of course, when it comes to the Marines, they must adapt and serve whatever the mission need and they have done so with distinction.

In regards to the long term affects, General Conway states: “Now, it is necessitated that we undergo these changes to the way we are constituted. But that’s OK. We made those adjustments. We’ll adjust back when the threat is different. But that’s adaptability…You create a force that you have to have at the time. But you don’t accept that as the new norm.”

As we know, in EA and other planning and transformation efforts, change for an organization—even the Marines—is not easy and resistances abound all around. How easy will it be for the Marines to return to their long term mission capabilities? And how should EA deal with short term business needs when they conflict with long term strategy for success?


Share/Save/Bookmark

December 21, 2007

Strategy and Enterprise Architecture

In the book Translating Strategy into Action, by Duke Corporate Education, the authors provide numerous insights into strategy development that are applicable to User-centric EA.

  • Strategy is hard—“As managers, the combination of more information, a faster pace, greater geographic reach, greater interdependence, and elevated scrutiny means the environment we manage and the problem we face are increasingly complex.” The EA strategy is hard to develop, but even harder for today’s overtaxed managers to quickly and simply execute.
  • Strategy is a differentiator—“Strategy is about being different and making choices…it outlines where and how a company will compete [or operate]…it provides direction, guidance, and focus when you are faced with choices.” The EA is a differentiator for where and how the organization will operate.
  • Strategy is purpose—“Creating strategic context for your team creates a greater sense of purpose by connecting what they are doing to the bigger picture.” The EA sets up an alignment between IT and business and establishes context and purpose.
  • Strategy must be adaptable—“Strategy will always be in a state of flux and should be adaptable to today’s fast-paced environment.” The EA must be flexible and adapt to a changing environment.
  • Information is king—“Implementing a strategy requires managers to move from data acquisition to insight. How managers make sense of information is what will set them and their companies apart.” In EA, information is captured, analyzed, and catalogued for developing strategy and enabling decision-making.
  • Always start with a baseline—“Strategy translation and execution always entails moving from where you are to where you want to be. Without an honest and incisive analysis of where you are, this journey begins on faulty ground.” In EA, you’ve got to have a baseline in order to get to your target.
  • Think capabilities—“The more important step is to focus on building the capabilities necessary to achieve these [strategic action] steps, and ultimately the intended vision.” EA should help you define and develop your operational and technical capabilities and competancies
  • Embrace change—“Get comfortable with change. Continue to learn how to adapt because the degree and pace of change is increasing. Your firm’s strategy will change, maybe not in major ways, but always in subtle and important ways.” EA requires that the enterprise is open to change, not for change’s sake, but for adapting to changes in our environment.

Enterprise architecture is a strategic, big picture endeavor. It involves developing the baseline, target, and transition plan. The EA is the enterprise strategy and blueprint for bridging information requirements with IT solutions. EA is the CIO’s strategy for meeting mission requirements.

Share/Save/Bookmark