Tag Archives: Enterprise architect

A Historical Look at Enterprise Architecture with John Zachman

By The Open Group

John Zachman’s Zachman Framework is widely recognized as the foundation and historical basis for Enterprise Architecture. On Tuesday, Feb. 3, during The Open Group’s San Diego 2015 event, Zachman will be giving the morning’s keynote address entitled “Zachman on the Zachman Framework and How it Complements TOGAF® and Other Frameworks.”

We recently spoke to Zachman in advance of the event about the origins of his framework, the state of Enterprise Architecture and the skills he believes EAs need today.

As a discipline, Enterprise Architecture is still fairly young. It began getting traction in the mid to late 1980s after John Zachman published an article describing a framework for information systems architectures in the IBM Systems Journal. Zachman said he lived to regret initially calling his framework “A Framework for Information Systems Architecture,” instead of “Enterprise Architecture” because the framework actually has nothing to do with information systems.

Rather, he said, it was “A Framework for Enterprise Architecture.” But at the time of publication, the idea of Enterprise Architecture was such a foreign concept, Zachman said, that people didn’t understand what it was. Even so, the origins of his ontological framework were already almost 20 years old by the time he first published them.

In the late 1960s, Zachman was working as an account executive in the Marketing Division of IBM. His account responsibility was working with the Atlantic Richfield Company (better known as ARCO). In 1969, ARCO had just been newly formed out of the merger of three separate companies, Atlantic Refining out of Philadelphia and Richfield in California, which merged and then bought Sinclair Oil in New York in 1969.

“It was the biggest corporate merger in history at the time where they tried to integrate three separate companies into one company. They were trying to deal with an enterprise integration issue, although they wouldn’t have called it that at the time,” Zachman said.

With three large companies to merge, ARCO needed help in figuring out how to do the integration. When the client asked Zachman how they should handle such a daunting task, he said he’d try to get some help. So he turned to a group within IBM called the Information Systems Control and Planning Group and the group’s Director of Architecture, Dewey Walker, for guidance.

Historically, when computers were first used in commercial applications, there already were significant “Methods and Procedures” systems communities in most large organizations whose job was to formalize many manual systems in order to manage the organization, Zachman said. When computers came on the scene, they were used to improve organizational productivity by replacing the people performing the organizations’ processes. However, because manual systems defined and codified organizational responsibilities, when management made changes within an organization, as they often did, it would render the computer systems obsolete, which required major redevelopment.

Zachman recalled Walker’s observation that “organizational responsibilities” and “processes” were two different things. As such, he believed systems should be designed to automate the process, not to encode the organizational responsibilities, because the process and the organization changed independently from one another. By separating these two independent variables, management could change organizational responsibilities without affecting or changing existing systems or the organization. Many years later, Jim Champy and Mike Hammer popularized this notion in their widely read 1991 book, “Reengineering the Corporation,” Zachman said.

According to Zachman, Walker created a methodology for defining processes as separate entities from the organizational structure. Walker came out to Los Angeles, where Zachman and ARCO were based to help provide guidance on the merger. Zachman recalls Walker telling him that the key to defining the systems for Enterprise purposes was in the data, not necessarily the process itself. In other words, the data across the company needed to be normalized so that they could maintain visibility into the assets and structure of the enterprise.

“The secret to this whole thing lies in the coding and the classification of the data,” Zachman recalled Walker saying. Walker’s methodology, he said, began by classifying data by its existence not by its use.

Since all of this was happening well before anyone came up with the concept of data modeling, there were no data models from which to design their system. “Data-oriented words were not yet in anyone’s vocabulary,” Zachman said. Walker had difficulty articulating his concepts because the words he had at his disposal were inadequate, Zachman said.

Walker understood that to have structural control over the enterprise, they needed to look at both processes and data as independent variables, Zachman said. That would provide the flexibility and knowledge base to accommodate escalating change. This was critical, he said, because the system is the enterprise. Therefore, creating an integrated structure of independent variables and maintaining visibility into that structure are crucial if you want to be able to manage and change it. Otherwise, he says, the enterprise “disintegrates.”

Although Zachman says Walker was “onto this stuff early on,” Walker eventually left IBM, leaving Zachman with the methodology Walker had named “Business Systems Planning.” (Zachman said Walker knew that it wasn’t just about the information systems, but about the business systems.) According to Zachman, he inherited Walker’s methodology because he’d been working closely with Walker. “I was the only person that had any idea what Dewey was doing,” he said.

What he was left with, Zachman says, was what today he would call a “Row 1 methodology”—or the “Executive Perspective” and the “Scope Contexts” in what would eventually become his ontology.

According to Zachman, Walker had figured out how to transcribe enterprise strategy in such a fashion that engineering work could be derived from it. “What we didn’t know how to do,” Zachman said, “was to transform the strategy (Zachman Framework Row 1), which tends to be described at a somewhat abstract level of definition into the operating Enterprise (Row 6), which was comprised of very precise instructions (explicit or implicit) for behavior of people and/or machines.”

Zachman said that they knew that “Architecture” had something to do with the Strategy to Instantiation transformation logic but they didn’t know what architecture for enterprises was in those days. His radical idea was to ask someone who did architecture for things like buildings, airplanes, locomotives, computers or battleships. What the architecture was for those Industrial Age products. Zachman believed if he could find out what they thought architecture was for those products, he might be able to figure out what architecture was for enterprises and thereby figure out how to transform the strategy into the operating enterprise to align the enterprise implementation with the strategy.

With this in mind, Zachman began reaching out to people in other disciplines to see how they put together things like buildings or airplanes. He spoke to an architect friend and also to some of the aircraft manufacturers that were based in Southern California at the time. He began gathering different engineering specs and studying them.

One day while he was sitting at his desk, Zachman said, he began sorting the design artifacts he’d collected for buildings and airplanes into piles. Suddenly he noticed there was something similar in how the design patterns were described.

“Guess what?” he said. “The way you describe buildings is identical to the way you describe airplanes, which turns out to be identical to the way you describe locomotives, which is identical to the way you describe computers. Which is identical to the way you describe anything else that humanity has ever described.”

Zachman says he really just “stumbled across” the way to describe the enterprise and attributes his discovery to providence, a miracle! Despite having kick-started the discipline of Enterprise Architecture with this recognition, Zachman claims he’s “actually not very innovative,” he said.

“I just saw the pattern and put enterprise names on it,” he said

Once he understood that Architectural design descriptions all used the same categories and patterns, he knew that he could also define Architecture for Enterprises. All it would take would be to apply the enterprise vocabulary to the same pattern and structure of the descriptive representations of everything else.

“All I did was, I saw the pattern of the structure of the descriptive representations for airplanes, buildings, locomotives and computers, and I put enterprise names on the same patterns,” he says. “Now you have the Zachman Framework, which basically is Architecture for Enterprises. It is Architecture for every other object known to human kind.”

Thus the Zachman Framework was born.

Ontology vs. Methodology

According to Zachman, what his Framework is ultimately intended for is describing a complex object, an Enterprise. In that sense, the Zachman Framework is the ontology for Enterprise Architecture, he says. What it doesn’t do, is tell you how to do Enterprise Architecture.

“Architecture is architecture is architecture. My framework is just the definition and structure of the descriptive representation for enterprises,” he said.

That’s where methodologies, such as TOGAF®, an Open Group standard, DoDAF or other methodological frameworks come in. To create and execute an Architecture, practitioners need both the ontology—to help them define, translate and place structure around the enterprise descriptive representations—and they need a methodology to populate and implement it. Both are needed—it’s an AND situation, not an OR, he said. The methodology simply needs to use (or reuse) the ontological constructs in creating the implementation instantiations in order for the enterprise to be “architected.”

The Need for Architecture

Unfortunately, Zachman says, there are still a lot of companies today that don’t understand the need to architect their enterprise. Enterprise Architecture is simply not on the radar of general management in most places.

“It’s not readily acknowledged on the general management agenda,” Zachman said.

Instead, he says, most companies focus their efforts on building and running systems, not engineering the enterprise as a holistic unit.

“We haven’t awakened to the concept of Enterprise Architecture,” he says. “The fundamental reason why is people think it takes too long and it costs too much. That is a shibboleth – it doesn’t take too long or cost too much if you know what you’re doing and have an ontological construct.”

Zachman believes many companies are particularly guilty of this type of thinking, which he attributes to a tendency to think that there isn’t any work being done unless the code is up and running. Never mind all the work it took to get that code up and running in the first place.

“Getting the code to run, I’m not arguing against that, but it ought to be in the context of the enterprise design. If you’re just providing code, you’re going to get exactly what you have right now—code. What does that have to do with management’s intentions or the Enterprise in its entirety?”

As such, Zachman compares today’s enterprises to log cabins rather than skyscrapers. Many organizations have not gotten beyond that “primitive” stage, he says, because they haven’t been engineered to be integrated or changed.

According to Zachman, the perception that Enterprise Architecture is too costly and time consuming must change. And, people also need to stop thinking that Enterprise Architecture belongs solely under the domain of IT.

“Enterprise Architecture is not about building IT models. It’s about solving general management problems,” he said. “If we change that perception, and we start with the problem and we figure out how to solve that problem, and then, oh by the way we’re doing Architecture, then we’re going to get a lot of Architecture work done.”

Zachman believes one way to do this is to build out the Enterprise Architecture iteratively and incrementally. By tackling one problem at a time, he says, general management may not even need to know whether you’re doing Enterprise Architecture or not, as long as their problem is being solved. The governance system controls the architectural coherence and integration of the increments. He expects that EA will trend in that direction over the next few years.

“We’re learning much better how to derive immediate value without having the whole enterprise engineered. If we can derive immediate value, that dispels the shibboleth—the misperception that architecture takes too long and costs too much. That’s the way to eliminate the obstacles for Enterprise Architecture.”

As far as the skills needed to do EA into the future, Zachman believes that enterprises will eventually need to have multiple types of architects with different skill sets to make sure everything is aligned. He speculates that someday, there may need to be specialists for every cell in the framework, saying that there is potentially room for a lot of specialization and people with different skill sets and a lot of creativity. Just as aircraft manufacturers need a variety of engineers—from aeronautic to hydraulic and everywhere in between—to get a plane built. One engineer does not engineer the entire airplane or a hundred-story building or an ocean liner, or, for that matter, a personal computer. Similarly, increasingly complex enterprises will likely need multiple types of engineering specialties. No one person knows everything.

“Enterprises are far more complex than 747s. In fact, an enterprise doesn’t have to be very big before it gets really complex,” he said. “As enterprise systems increase in size, there is increased potential for failure if they aren’t architected to respond to that growth. And if they fail, the lives and livelihoods of hundreds of thousand of people can be affected, particularly if it’s a public sector Enterprise.”

Zachman believes it may ultimately take a generation or two for companies to understand the need to better architect the way they run. As things are today, he says, the paradigm of the “system process first” Industrial Age is still too ingrained in how systems are created. He believes it will be a while before that paradigm shifts to a more Information Age-centric way of thinking where the enterprise is the object rather than the system.

“Although this afternoon is not too early to start working on it, it is likely that it will be the next generation that will make Enterprise Architecture an essential way of life like it is for buildings and airplanes and automobiles and every other complex object,” he said.

By The Open GroupJohn A. Zachman, Founder & Chairman, Zachman International, Executive Director of FEAC Institute, and Chairman of the Zachman Institute

Join the conversation – @theopengroup, #ogchat, #ogSAN

3 Comments

Filed under Enterprise Architecture, Standards, TOGAF®, Uncategorized

Enterprise Architecture: A Practitioner View

By Prasad Palli and Dr. Gopala Krishna Behara, Wipro

Overview of Enterprise Architecture

IT organizations as usual are always ready to take challenges and start the journey in defining/refining their IT strategies and aligning with business strategies. During this journey, enterprises adopt a framework / methodology / best-practice / pattern / process called “Enterprise Architecture” which will help them to structure their processes and address growth together.

The effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. Enterprise Architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

Without Enterprise Architecture

Based on our experience in Enterprise Architecture consulting, we highlight the common mistakes/frequent issues faced by the organizations in the absence of Enterprise Architecture.

Strategy

  • No link to business strategic planning and budget process
  • Slow and ineffective decision-making
  • Inability to rapidly respond to changes driven by business challenges
  • Lack of focus on enterprise requirements
  • Lack of common direction and synergies
  • Focusing on the art or language of EA rather than outcomes
  • Incomplete visibility of the current and future target Enterprise Architecture vision

Governance

  • Inability to predict impacts of future changes
  • Confusing “IT Architecture” With “Enterprise Architecture”
  • Lack of governance
  • Strict following of EA frameworks
  • “Ivory Tower” approach
  • Lack of communication and feedback
  • Limiting the EA team to IT resources
  • Lack of performance measures
  • No measurement criteria for EA metrics
  • Picking a tool before understanding your business needs

Technology

  • Increased gaps and architecture conflicts
  • Lack of commonality and consistency due to the absence of standards
  • Dilution and dissipation of critical information and knowledge of the deployed solutions
  • Rigidity, redundancy and lack of scalability and flexibility in the deployed solutions
  • Over-standardization
  • Non-adoption of Next Generation Technologies
  • Lack of integration, compatibility and interoperability between applications
  • Complex, fragile and costly interfaces between incongruent application

Enterprise Architecture Perspective

The main drivers of Enterprise Architecture of the enterprise are:

  • Highly optimized and flexible processes (Business & IT)
  • Ability to integrate seamlessly with systems within the enterprise and partners
  • Highly optimized and shared IT infrastructure
  • Loosely coupled systems to quickly respond to new processes or new product or new channel – Business value generation
  • Well mapping of business processes to application to information to technology
  • Strict adherence to regulatory and compliance factors

This article highlights our framework of Enterprise Architecture and its roadmap for the development and management of various components. It depicts how these components work together, what are the various measures of business units, enterprise and their outcome. The framework includes putting in place the proper organizational structure and hybrid business/IT roles, consolidating and standardizing information and data stores, and integrating applications and infrastructure to support the right business processes across the enterprise.

The key Components of Enterprise Architecture are depicted below.

EA1

EA – Practical Experience

Enterprise Architecture is not a one-time event, nor limited to specific projects or business units. EA is an on-going, iterative process that provides:

  • A common vision of the future shared by business and IT; business aware of IT and vice-versa
  • Guidance in the selection, creation and implementation of solutions driven by business requirements
  • Support for the various enterprise business lines through improved information sharing – provides plan for the integration of information and services at the design level across business lines
  • A means to control growing complexities of technology by setting enterprise-wide, leverageable standards for information technology
  • Defines an approach for the evaluation, consideration and assimilation of new and emerging technology innovations to meet business requirements

Some of the key aspects that teams will come across during EA execution:

  • EA is NOT a project: This is one of common mistake that most enterprises do. Enterprise Architecture is NOT a project, which can be delivered within specified timeframe. Enterprise Architecture is more of a culture that enterprises must adopt like SDLC process.
  • EA is NOT about review : Generally, people tend to think that EA is always for review and do policing team/individual performance and provide review reports to higher management. Instead EA is of bringing standards and making enterprise flexible to address changes as needed for business growth.
  • EA is NOT a one-time activity: The success of EA is possible only when enterprises will adopt it as part of their culture. For this to happen, Enterprise Architecture should execute as an iterative and on-going process and educate all stakeholders (business, portfolio managers, architects, program/project managers, designers, developers, operations, partners etc.) about the initiative and make them responsible for EA success.
  • EA is NOT for IT: Most of the times Enterprise Architecture initiative is driven by IT organizations without much involvement from Business. This is the first step towards a big failure. Depending upon the approach (whether it is top-down or bottom-up), business should be aware of what’s happening in the Enterprise Architecture initiative and be actively participating in the program when needed. Business is as equally responsible as IT for the success of an EA initiative.
  • EA is NOT a strategy: There is a common view across organizations that Enterprise Architecture is more of a strategy and teams like solution architecture, portfolio management and design & development and operations streams doesn’t have a role to play. In fact, the aforementioned teams are key contributors to Enterprise Architecture definition and its success by inculcating EA standards and best practices in their day-to-day activities.
  • EA is NOT all about cost-reduction: Most of the enterprises will look at EA from cost savings perspective that puts lot of pressure on IT to show some immediate benefits in terms of savings. With this kind of pressure, EA will get off track and be seen as more of a tactical initiative rather than strategic. Enterprises should start looking at EA more from Business-IT alignment, agility, innovation etc. which are strategic in nature along with cost savings.
  • EA is NOT one-man show: Enterprise Architecture is neither a CIO job or CFO or any CXO. It’s everybody’s job within an enterprise. During the EA strategy definition phase, probably more leadership involvement is needed and at EA implementation stage all the stakeholders will have a role to play and contribute one way or another.
  • EA is all about communication: One of the common mistakes that most enterprises do during the EA program is the team will work in silos and build huge pile of documents without having proper communication sessions within enterprise. At a minimum, the EA team should spend 50% of efforts towards communicating EA artifacts with the team and successful medium is through meetings rather than sending over emails or website.
  • Measure EA: During the initial stages of an EA program, the team should define measuring criteria/factors of EA (for ex: customer satisfaction, time to market, agility, cost savings, standardization, resources skills, trainings/certification etc.). Without these factors defined, EA will end up in ad-hoc planning which leads to chaos and frustrates leadership.
  • Adoption of Latest Technology Trends on EA: Traditional EA is more of the “Ivory Tower” approach which is modeled as framework-centered and tool-driven. Most of the EA function is technology-centric and defined as a one-time initiative. Application built on Traditional EA principles are business-constraint before they are completed. The Next Generation Enterprise Architecture (NGEA) is business-centric, global, agile, continuous and social digital network. Also, the organizations adopt latest digital capabilities like social web, SOA, big data analytics, omni channel customer management, cloud computing, virtualization, Internet of Things and so on. These technologies are interrelated and fit together to define Next Generation Enterprise Architecture for an organization.

The vision of an enterprise is shifting from Traditional EA to Digital Architecture which addresses Networked Community Capabilities (interacting with users through social media), globalization (Borderless Enterprise), innovation of products and services (open, closed & virtual innovation), collaboration (enable employees in decision-making, location flexibility, schedule flexibility), flexibility (flexibility to choose the technologies, infrastructure, applications).

The following diagram shows the Next Generation EA Model.

EA2

  • Network-centric enterprise: Online communities, workforce (network/social collaboration), business partners, customers and the marketplace
  • Enterprise resources: Teams, project-centric, process-based work conducted by communities
  • Business partners: Strategic partners and suppliers can be engaged together in operations
  • Customers: Customer care communities
  • Outside enterprise: Regulators, influencers, crowdsourcing participants, software developers and other interested parties
  • Third party vendors: Packaged vendors like SAP, Oracle ERP etc.
  • New channels: Web, mobile devices, Social business environments (communities of all functional types and audiences) and CRM

Conclusions

This article attempts to demonstrate practical views of an Enterprise Architect in improving the success rate of EA across the organizations. There is no hard and fast rule that enterprises should adopt to one particular framework or standard or approach. They can choose to adopt any industry specific framework, however it can be customized as per the needs of the enterprise. It does not force fit EA programs to any industry framework. The deliverables of EA should integrate with business planning, focus on business architecture and defining/streamlining business outcome metrics.

EA program definition should not span for years. It should deliver business value in months or weeks. Also, the program output should be actionable. Always measure impact but not activity.

Apart from these steps, enterprise should think about following other key aspects like:

  • Should have strong leadership commitments
  • Not always as-Is instead it can start with defining future state
  • Start with the highest-priority business outcomes

Use the right diagnostic tools — EAs must have a broad set of tools to choose from:

  • Ensure the program outputs are actionable
  • Measure impact, not activity
  • Adopt Next Generation Enterprise Architecture patterns
  • Socialize, listen, crowd source and be transparent
  • Do not re-architect legacy systems for the sake of re-architecting: most old systems should be wrapped, then replaced
  • Prepare to measure degree of success before starting on with the new architecture initiative
  • Do not over-design your systems of innovation or under-design the systems of differentiation or record

References

1.http://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm

Acknowledgements

The authors would like to thank Hari Kishan Burle, Raju Alluri of Architecture Group of Wipro Technologies for giving us the required time and support in many ways in bringing this article as part of Enterprise Architecture Practice efforts.

Authors

PalliPrasad Palli is a Practice Partner in the Enterprise Architecture division of Wipro. He has a total of 17 years of IT experience. He can be reached at prasad.palli@wipro.com

 

BeharaDr. Gopala Krishna Behara is a Senior Enterprise Architect in the Enterprise Architecture division of Wipro. He has a total of 18 years of IT experience. He can be reached at gopalkrishna.behra@wipro.com

 

Disclaimer

The views expressed in this article/presentation are that of authors and Wipro does not subscribe to the substance, veracity or truthfulness of the said opinion.

1 Comment

Filed under Enterprise Architecture, Enterprise Transformation, Governance, IT, Standards

Now is the Time for Third Generation Enterprise Architecture Methods

By Erwin Oord, Principal Consultant Enterprise Architecture and Managing Partner at Netherlands-based ArchiXL Consultancy

Common methods for Enterprise Architecture used at present have been around for ages already. Although these methods have made a strong contribution to the development of the architecture discipline, they have reached the limits of their abilities. It is time to make a leap forward and for that we need a new generation of architecture methods. What characterizes architecture methods of this new generation?

Architects currently working with methods like TOGAF®, an Open Group standard, DYA or IAF might not realize it, but these methods stem from the early days of the architecture discipline. DYA originated in 2001 and the first version of TOGAF dates back to even 1995! Of course, these architecture methods are not dinosaurs that forgot to extinct. TOGAF produces new versions that are the result of lively discussion at The Open Group.

But an architecture method is like a car model. With annual facelifts you can adjust to the latest fashion, but you cannot hide the fact that the basic product reflects the spirit of the time in which it was developed. Car models, including those of the better car brands, reach their end after a decade or so. The automotive industry is used to this and knows that this cycle requires high investments, but also brings new opportunities. Enterprise Architecture is no different!

Let’s take a look back in history. The notion of Enterprise Architecture emerged in the mid-eighties. In that period, people like Zachman discovered that systems development models together create a coherent view on the enterprise. Thus arose the first architectural frameworks. This is the first generation of architecture methods, although a “method” was barely recognized.

The need for a repeatable process to develop and use architecture models emerged in the nineties. This is the time when the famous TOGAF Architecture Development Method came about, later followed by the concept of the strategic dialogue in DYA. This process-oriented approach to Enterprise Architecture was a great leap forward. We can therefore speak of a second generation of architecture methods.

A shocking discovery is that since then not much more has happened. Of course, methods have evolved with the addition of reference models and techniques for creating models. The underlying content frames have improved, now including architectural principles and implementation aspects. But all this is merely facelifting. We are still working with basic designs dating back more than a decade.

In order to make a leap forward again, we must escape the current process orientation. Instead of focusing on a fixed process to develop and use architecture, we must focus on the results of architecture. But that is only possible when we realize architecture is not a process in itself but an aspect of the overall change process in an organization. After all, governments and companies are constantly changing. An architecture method should therefore not be self-contained, but should be fully integrated in the change process.

A third generation architecture method has no fixed processes but focuses on essential architecture tasks, and integrates these tasks in the change methodology used by the organization. It provides a limited set of clearly defined architectural products that can be used directly in the change process. And it recognizes clearly defined roles that, depending on the situation, can be assigned to the right stakeholders. And that is certainly not always the Enterprise Architect. The key of a third generation Enterprise Architecture method is not the method itself but the way it is integrated into the organization.

OordErwin Oord, Principal Consultant Enterprise Architecture and Managing Partner at Netherlands based ArchiXL consultancy, has a rich experience in applying and customising Enterprise Architecture methods in both public sector and business organisations. Being co-author of a successful (Dutch) guide on selecting appropriate architecture methods, he is frequently asked for setting up an architecture practice or advancing architecture maturity stages in organisations. In his assignments, he focuses on effective integration of architecture with business and organisation change management.

6 Comments

Filed under Enterprise Architecture, Standards, TOGAF®, Uncategorized

Discussing Enterprise Decision-Making with Penelope Everall Gordon

By The Open Group

Most enterprises today are in the process of jumping onto the Big Data bandwagon. The promise of Big Data, as we’re told, is that if every company collects as much data as they can—about everything from their customers to sales transactions to their social media feeds—executives will have “the data they need” to make important decisions that can make or break the company. Not collecting and using your data, as the conventional wisdom has it, can have deadly consequences for any business.

As is often the case with industry trends, the hype around Big Data contains both a fair amount of truth and a fair amount of fuzz. The problem is that within most organizations, that conventional wisdom about the power of data for decision-making is usually just the tip of the iceberg when it comes to how and why organizational decisions are made.

According to Penelope Gordon, a consultant for 1Plug Corporation who was recently a Cloud Strategist at Verizon and was formerly a Service Product Strategist at IBM, that’s why big “D” (Data) needs to be put back into the context of enterprise decision-making. Gordon, who spoke at The Open Group Boston 2014, in the session titled “Putting the D Back in Decision” with Jean-Francois Barsoum of IBM, argues that a focus on collecting a lot of data has the potential to get in the way of making quality decisions. This is, in part, due to the overabundance of data that’s being collected under the assumption that you never know where there’s gold to be mined in your data, so if you don’t have all of it at hand, you may just miss something.

Gordon says that assuming the data will make decisions obvious also ignores the fact that ultimately decisions are made by people—and people usually make decisions based on their own biases. According to Gordon, there are three types of natural decision making styles—heart, head and gut styles—corresponding to different personality types, she said; the greater the amount of data the more likely that it will not balance the natural decision-making style.

Head types, Gordon says, naturally make decisions based on quantitative evidence. But what often happens is that head types often put off making a decision until more data can be collected, wanting more and more data so that they can make the best decision based on the facts. She cites former President Bill Clinton as a classic example of this type. During his presidency, he was famous for putting off decision-making in favor of gathering more and more data before making the decision, she says. Relying solely on quantitative data also can mean you may miss out on other important factors in making optimal decisions based on either heart (qualitative) or instinct. Conversely, a gut-type presented with too much data will likely just end up ignoring data and acting on instinct, much like former President George W. Bush, Gordon says.

Gordon believes part of the reason that data and decisions are more disconnected than one might think is because IT and Marketing departments have become overly enamored with what technology can offer. These data providers need to step back and first examine the decision objectives as well as the governance behind those decisions. Without understanding the organization’s decision-making processes and the dynamics of the decision-makers, it can be difficult to make optimal and effective strategic recommendations, she says, because you don’t have the full picture of what the stakeholders will or will not accept in terms of a recommendation, data or no data.

Ideally, Gordon says, you want to get to a point where you can get to the best decision outcome possible by first figuring out the personal and organizational dynamics driving decisions within the organization, shifting the focus from the data to the decision for which the data is an input.

“…what you’re trying to do is get the optimal outcome, so your focus needs to be on the outcome, so when you’re collecting the data and assessing the data, you also need to be thinking about ‘how am I going to present this data in a way that it is going to be impactful in improving the decision outcomes?’ And that’s where the governance comes into play,” she said.

Governance is of particular importance now, Gordon says, because decisions are increasingly being made by individual departments, such as when departments buy their own cloud-enabled services, such as sales force automation. In that case, an organization needs to have a roadmap in place with compensation to incent decision-makers to adhere to that roadmap and decision criteria for buying decisions, she said.

Gordon recommends that companies put in place 3-5 top criteria for each decision that needs to be made so that you can ensure that the decision objectives are met. This distillation of the metrics gives decision-makers a more comprehensible picture of their data so that their decisions don’t become either too subjective or disconnected from the data. Lower levels of metrics can be used underneath each of those top-level criteria to facilitate a more nuanced valuation. For example, if an organization needing to find good partner candidates scored and ranked (preferably in tiers) potential partners using decision criteria based on the characteristics of the most attractive partner, rather than just assuming that companies with the best reputation or biggest brands will be the best, then they will expeditiously identify the optimal partner candidates.

One of the reasons that companies have gotten so concerned with collecting and storing data rather than just making better decisions, Gordon believes, is that business decisions have become inherently more risky. The required size of investment is increasing in tandem with an increase in the time to return; time to return is a key determinant of risk. Data helps people feel like they are making competent decisions but in reality does little to reduce risk.

“If you’ve got lots of data, then the thinking is, ‘well, I did the best that I could because I got all of this data.’ People are worried that they might miss something,“ she said. “But that’s where I’m trying to come around and say, ‘yeah, but going and collecting more data, if you’ve got somebody like President Clinton, you’re just feeding into their tendency to put off making decisions. If you’ve got somebody like President Bush and you’re feeding into their tendency to ignore it, then there may be some really good information, good recommendations they’re ignoring.”

Gordon also says that having all the data possible to work with isn’t usually necessary—generally a representative sample will do. For example, she says the U.S Census Bureau takes the approach where it tries to count every citizen; consequently certain populations are chronically undercounted and inaccuracies pass undetected. The Canadian census, on the other hand, uses representative samples and thus tends to be much more accurate—and much less expensive to conduct. Organizations should also think about how they can find representative or “proxy” data in cases where collecting data that directly addresses a top-level decision criteria isn’t really practical.

To begin shifting the focus from collecting data inputs to improving decision outcomes, Gordon recommends clearly stating the decision objectives for each major decision and then identifying and defining the 3-5 criteria that are most important for achieving the decision objectives. She also recommends ensuring that there is sufficient governance and a process in place for making decisions including mechanisms for measuring the performance of the decision-making process and the outcomes resulting from the execution of that process. In addition, companies need to consider whether their decisions are made in a centralized or decentralized manner and then adapt decision governance accordingly.

One way that Enterprise Architects can help to encourage better decision-making within the organizations in which they work is to help in developing that governance rather than just providing data or data architectures, Gordon says. They should help stakeholders identify and define the important decision criteria, determine when full population rather than representative sampling is justified, recognize better methods for data analysis, and form decision recommendations based on that analysis. By gauging the appropriate blend of quantitative and qualitative data for a particular decision maker, an Architect can moderate gut types’ reliance on instinct and stimulate head and heart types’ intuition – thereby producing an optimally balanced decision. Architects should help lead and facilitate execution of the decision process, as well as help determine how data is presented within organizations in order to support the recommendations with the highest potential for meeting the decision objectives.

Join the conversation – #ogchat

penelopegordonPenelope Gordon recently led the expansion of the channel and service packaging strategies for Verizon’s cloud network products. Previously she was an IBM Strategist and Product Manager bringing emerging technologies such as predictive analytics to market. She helped to develop one of the world’s first public clouds.

 

 

2 Comments

Filed under architecture, Conference, Data management, Enterprise Architecture, Governance, Professional Development, Uncategorized

What the C-Suite Needs to Prepare for in the Era of BYO Technology

By Allen Brown, President and CEO, The Open Group

IT today is increasingly being driven by end-users. This phenomenon, known as the “consumerization of IT,” is a result of how pervasive technology has become in daily life. Years ago, IT was the primarily the realm of technologists and engineers. Most people, whether in business settings or at home, did not have the technical know-how to source their own applications, write code for a web page or even set up their own workstation.

Today’s technologies are more user-friendly than ever and they’ve become ubiquitous. The introduction of smartphones and tablets has ushered in the era of “BYO” with consumers now bringing the technologies they like and are most comfortable working with into the workplace, all with the expectation that IT will support them. The days where IT decided what technologies would be used within an organization are no more.

At the same time, IT has lost another level of influence due to Cloud computing and Big Data. Again, the “consumers” of IT within the enterprise—line of business managers, developers, marketers, etc.—are driving these changes. Just as users want the agility offered by the devices they know and love, they also want to be able to buy and use the technologies they need to do their job and do it on the fly rather than wait for an IT department to go through a months’ (or years’) long process of requisitions and approvals. And it’s not just developers or IT staff that are sourcing their own applications—marketers are buying applications with their credit cards, and desktop users are sharing documents and spreadsheets via web-based office solutions.

When you can easily buy the processing capacity you need when you need it with your credit card or use applications online for free, why wait for approval?

The convergence of this next era of computing – we call it Open Platform 3.0™ – is creating a Balkanization of the traditional IT department. IT is no longer the control center for technology resources. As we’ve been witnessing over the past few years and as industry pundits have been prognosticating, IT is changing to become more of a service-based command central than a control center from which IT decisions are made.

These changes are happening within enterprises everywhere. The tides of change being brought about by Open Platform 3.0 cannot be held back. As I mentioned in my recent blog on Future Shock and the need for agile organizations, adaptation will be key for companies’ survival as constant change and immediacy become the “new normal” for how they operate.

These changes will, in fact, be positive for most organizations. As technologies converge and users drive the breakdown of traditional departmental silos and stovepipes, organizations will become more interoperable. More than ever, new computing models are driving the industry toward The Open Group’s vision of Boundaryless Information Flow™ within organizations. But the changes resulting from consumer-led IT are not just the problem of the IT department. They are on track to usher in a whole host of organizational changes that all executives must not only be aware of, but must also prepare and plan for.

One of the core of issues around consumerized IT that must be considered is the control of resources. Resource planning in terms of enabling business processes through technology must now be the concern of every person within the C-Suite from the CEO to the CIO and even the CMO.

Take, for example, the financial controls that must be considered in a BYO world. This issue, in particular, hits two very distinct centers of operations most closely—the offices of both the CIO and the CFO.

In the traditional IT paradigm, technology has been a cost center for most businesses with CFOs usually having the final say in what technologies can be bought and used based on budget. There have been very specific controls placed on purchases, each leaving an audit trail that the finance department could easily track and handle. With the Open Platform 3.0 paradigm, those controls go straight out the window. When someone in marketing buys and uses an application on their own without the CIO approving its use or the CFO having an paper trail for the purchase, accounting and financial or technology auditing can become a potential corporate nightmare.

Alternatively, when users share information over the Web using online documents, the CIO, CTO or CSO may have no idea what information is going in and out of the organization or how secure it is. But sharing information through web-based documents—or a CRM system—might be the best way for the CMO to work with vendors or customers or keep track of them. The CMO may also need to begin tracking IT purchases within their own department.

The audit trail that must be considered in this new computing era can extend in many directions. IT may need an accounting of technical and personal assets. Legal may need information for e-Discovery purposes—how does one account for information stored on tablets or smartphones brought from home or work-related emails from sent from personal accounts? The CSO may require risk assessments to be performed on all devices or may need to determine how far an organization’s “perimeter” extends for security purposes. The trail is potentially as large as the organization itself and its entire extended network of employees, vendors, customers, etc.

What can organizations do to help mitigate the potential chaos of a consumer-led IT revolution?

Adapt. Be flexible and nimble. Plan ahead. Strategize. Start talking about what these changes will mean for your organization—and do it sooner rather than later. Work together. Help create standards that can help organizations maintain flexible but open parameters (and perimeters) for sourcing and sharing resources.

Executive teams, in particular, will need to know more about the functions of other departments than ever before. IT departments—including CTOs and EAs—will need to know more about other business functions—such as finance—if they are to become IT service centers. CFOs will need to know more about technology, security, marketing and strategic planning. CMOs and CIOs will need to understand regulatory guidelines not only around securing information but around risk and data privacy.

Putting enterprise and business architectures and industry standards in place can go a long way toward helping to create structures that maintain a healthy balance between providing the flexibility needed for Open Platform 3.0 and BYO while allowing enough organizational control to prevent chaos. With open architectures and standards, organizations will better be able to decide where controls are needed and when and how information should be shared among departments. Interoperability and Boundaryless Information Flow—where and when they’re needed—will be key components of these architectures.

The convergence being brought about Open Platform 3.0 is not just about technology. It’s about the convergence of many things—IT, people, operations, processes, information. It will require significant cultural changes for most organizations and within different departments and organizational functions that are not used to sharing, processing and analyzing information beyond the silos that have been built up around them.

In this new computing model, Enterprise Architectures, interoperability and standards can and must play a central role in guiding the C-Suite through this time of rapid change so that users have the tools they need to be able to innovate, executives have the information they need to steer the proverbial ship and organizations don’t get left behind.

brown-smallAllen Brown is the President and CEO of The Open GroupFor more than ten years, he has been responsible for driving the organization’s strategic plan and day-to-day operations; he was also instrumental in the creation of the Association of Enterprise Architects (AEA). Allen is based in the U.K.

Comments Off on What the C-Suite Needs to Prepare for in the Era of BYO Technology

Filed under Business Architecture, Cloud/SOA, Enterprise Architecture, Enterprise Transformation, Standards, Uncategorized

The Open Group London 2013 – Day One Highlights

By Loren K. Baynes, Director, Global Marketing Communications

On Monday October 21st, The Open Group kicked off the first day of our Business Transformation conference in London!  Over 275 guests attended many engaging presentations by subject matter experts in finance, healthcare and government.  Attendees from around the globe represented 28 countries including those from as far away as Columbia, Philippines, Australia, Japan and South Africa.

Allen Brown, President and CEO of The Open Group, welcomed the prestigious group.  Allen announced that The Open Group has 67 new member organizations so far this year!

The plenary launched with “Just Exactly What is Going On in Business and Technology?” by Andy Mulholland, Former Global CTO of Capgemini, who was named one of the top 25 influential CTOs by InfoWorld.  Andy’s key topics regarding digital disruption included real drivers of change, some big and fundamental implications, business model innovation, TOGAF® and the Open Platform 3.0™ initiative.

Next up was Judith Jones, CEO, Architecting the Enterprise Ltd., with a presentation entitled “One World EA Framework for Governments – The Way Forward”.  Judith shared findings from the World Economic Forum, posing the question “what keeps 1000 global leaders awake at night”? Many stats were presented with over 50 global risks – economical, societal, environmental, geopolitical and technological.

Jim Hietala, VP, Security of The Open Group announced the launch of the Open FAIR Certification for People Program.  The new program brings a much-needed certification to the market which focuses on risk analysis. Key partners include CXOWARE, Architecting the Enterprise, SNA Technologies and The Unit bv.

Richard Shreeve, Consultancy Director, IPL and Angela Parratt, Head of Transformation and joint CIO, Bath and North East Somerset Council presented “Using EA to Inform Business Transformation”.  Their case study addressed the challenges of modeling complexity in diverse organizations and the EA-led approach to driving out cost and complexity while maintaining the quality of service delivery.

Allen Brown announced that the Jericho Forum® leaders together with The Open Group management have concluded that the Jericho Forum has achieved its original mission – to establish “de-perimeterization” that touches all areas of modern business.  In declaring this mission achieved, we are now in the happy position to celebrate a decade of success and move to ensuring that the legacy of the Jericho Forum is both maintained within The Open Group and continues to be built upon.  (See photo below.)

Following the plenary, the sessions were divided into tracks – Finance/Commerce, Healthcare and Tutorials/Workshops.

During the Healthcare track, one of the presenters, Larry Schmidt, Chief Technologist with HP, discussed “Challenges and Opportunities for Big Data in Healthcare”. Larry elaborated on the 4 Vs of Big Data – value, velocity, variety and voracity.

Among the many presenters in the Finance/Commerce track, Omkhar Arasaratnam, Chief Security Architect, TD Bank Group, Canada, featured “Enterprise Architecture – We Do That?: How (not) to do Enterprise Architecture at a Bank”.  Omkhar provided insight as to how he took traditional, top down, center-based architectural methodologies and applied it to a highly federated environment.

Tutorials/workshops consisted of EA Practice and Architecture Methods and Techniques.

You can view all of the plenary and many of the track presentations at livestream.com.  For those who attended, please stay tuned for the full conference proceedings.

The evening concluded with a networking reception at the beautiful and historic and Central Hall Westminster.  What an interesting, insightful, collaborative day it was!

IMG_1311

Comments Off on The Open Group London 2013 – Day One Highlights

Filed under Business Architecture, Certifications, Cloud, Cloud/SOA, Conference, Cybersecurity, Information security, Open Platform 3.0, Professional Development, RISK Management, Security Architecture, Standards, TOGAF®

Leading Business Disruption Strategy with Enterprise Architecture

By Patty Donovan, The Open Group

On Wednesday, October 2nd, The Open Group and Enterprise Architects will host a tweet jam which discusses how organisations can lead business disruption with Enterprise Architecture (EA). Today, businesses are being forced to come to terms with their vulnerabilities and opportunities when it comes to disruptive innovation. Enterprise Architecture, by leveraging its emergent business architecture capabilities and its traditional technology and innovation focus, has the opportunity to fill a key void, aiding businesses to win in this new world.

In the recently published Hype Cycle for Enterprise Architecture 2013 Gartner places disruptive forces at the center of the emerging EA mandate:

“Enterprise Architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.”

“EA practitioners have the opportunity to take a quantum leap toward not only becoming integral to the business, but also leading business change.”

Source: Hype Cycle for Enterprise Architecture 2013, Gartner 2013

Please join us on Wednesday, October 2nd at 12noon BST for our upcoming “Leading Disruption Strategy with EA” tweet jam where leading experts will discuss this evolving topic.

We welcome Open Group members and interested participants from all backgrounds to join the session and interact with our panel thought leaders, led by Hugh Evans, CEO of Enterprise Architects (@enterprisearchs). To access the discussion, please follow the #ogChat hashtag during the allotted discussion time.

Planned questions include:

  • Q1 What is #Disruption?
  • Q2 What is #Digitaldisruption?
  • Q3 What are good examples of disruptive #Bizmodels?
  • Q4 What is the role of #EntArch in driving and responding to #disruption?
  • Q5 Why is #EntArch well placed to respond to #Disruption?
  • Q6 Who are the key stakeholders #EntArch needs to engage when developing a #Disruption strategy?
  • Q7 What current gaps in #EntArch must be filled to effectively lead #Disruption strategy?

Additional appropriate hashtags:

  • #EntArch – Enterprise Architecture
  • #BizArch – Business Architecture
  • #Disruption – Disruption
  • #DigitalDisruption – Digital Disruption
  • #Bizmodels – Business Models
  • #ogArch – The Open Group Architecture Forum

And for those of you who are unfamiliar with tweet jams, here is some background information:

What Is a Tweet Jam?

A tweet jam is a one hour “discussion” hosted on Twitter. The purpose of this tweet jam is to share knowledge and answer questions on leading business disruption strategy with enterprise architecture. Each tweet jam is led by a moderator and a dedicated group of experts to keep the discussion flowing. The public (or anyone using Twitter interested in the topic) is encouraged to join the discussion.

Participation Guidance

Whether you’re a newbie or veteran Twitter user, here are a few tips to keep in mind:

  • Have your first #ogChat tweet be a self-introduction: name, affiliation, occupation.
  • Start all other tweets with the question number you’re responding to and the #ogChat hashtag.
    • Sample: “Big Data presents a large business opportunity, but it is not yet being managed effectively internally – who owns the big data function? #ogchat”
    • Please refrain from product or service promotions. The goal of a tweet jam is to encourage an exchange of knowledge and stimulate discussion.
    • While this is a professional get-together, we don’t have to be stiff! Informality will not be an issue!
    • A tweet jam is akin to a public forum, panel discussion or Town Hall meeting – let’s be focused and thoughtful.

If you have any questions prior to the event or would like to join as a participant, please direct them to Rob Checkal (rob.checkal at hotwirepr.com). We anticipate a lively chat and hope you will be able to join!

patricia donovanPatricia Donovan is Vice President, Membership & Events, at The Open Group and a member of its executive management team. In this role she is involved in determining the company’s strategic direction and policy as well as the overall management of that business area. Patricia joined The Open Group in 1988 and has played a key role in the organization’s evolution, development and growth since then. She also oversees the company’s marketing, conferences and member meetings. She is based in the U.S.

2 Comments

Filed under Business Architecture, Enterprise Architecture, Future Technologies, Open Platform 3.0, Platform 3.0, Tweet Jam