Search Results for: zachman

Will Enterprise Architecture Ever “Cross the Chasm?”

by

The profession of Enterprise Architecture is beginning to emerge from its early stages of development. The number of people professing the title of Enterprise Architect has grown from a relative few in the 1990s to thousands today. On LinkedIn, a popular social networking site for professionals, the “Enterprise Architecture Network” discussion group boasts over 79,000 members.

There is a great deal of demand for Enterprise Architecture services. Large consulting firms like Accenture, Deloitte, PWC, and Wipro, large software vendors like Microsoft and IBM, large hardware vendors like Fujitsu and Hewlett Packard, and outsourcing firms like Computer Sciences Corporation, have all developed service offerings that revolve around providing Enterprise Architecture as a service to their clients.

While the field has grown, the proliferation of voices, methods, frameworks, and generally inconsistent advice in the field of EA has also grown. The number of “EA Frameworks” has grown to include a wide array of overlapping bodies of work. Included in this list are GERAM, TOGAF, FEAF, MODAF, DODAF, PEAF, E2AF, Zachman, and many others. Jaap Schekkerman has released three editions of his 250+ page book “How to Survive in the Jungle of Enterprise Architecture Frameworks” which attempts to compare only 15 of them!

Unfortunately this proliferation has created a problem that is common among emerging professions: a lack of maturity. As Geoffrey A. Moore pointed out in his landmark book, “Crossing the Chasm,” the market for a high-tech product will self-segment into Early Adopters (accounting for less than 20% of the market) and the more pragmatic customers in the Early Majority, Late Majority, and Laggards categories. Viewing Enterprise Architecture as a new high-tech product provides useful insight into why EA has failed to “cross the chasm” from early adoption to the pragmatic majority.

In order for Enterprise Architecture to cross the chasm, there has to be an intentional strategy to gain a foothold in one target market that is part of the Early Majority, and then to use the success of Enterprise Architecture in that space to build the credibility needed for other segments to adopt.

Unfortunately, while EA has been successful in some target markets in the Early Majority (like Telecom and Federal), the lack of consistency in the approach, terminology, and even value proposition of EA across industries poses an obstacle for increasing EA adoption. In other words, the success of EA in one or two areas is failing to help EA gain a foothold among other industries. Could it be because they don’t use the same words to describe success?

Unable to depend on a broader “EA movement,” each EA team is waging a lonely struggle for relevance and ongoing support within their own enterprise. To remain relevant, EA teams have often focused on “low hanging fruit,” immediately valuable initiatives that generate results quickly but often fail to address long-standing challenges. The mantra of modern Enterprise Architecture has become “provide immediate value immediately,” a position that relegates long-term thinking and investment to another day. Ironically, it is this long-term thinking and investment that EA is supposed to provide.

It should come as no surprise that a profession that is designed to provide value in the long term is struggling with demonstrating short-term results. Many EA programs fail as a result of this struggle. In a widely publicized study commissioned by EA tools vendor IDS Sheer, Jonathan Broer, then an undergraduate researcher from Rotterdam University, conducted a study of 191 organizations. The startling results of his survey suggest that up to 66% of all EA-sponsored efforts have failed to produce the expected results. Of the root causes cited: the lack of business awareness of Enterprise Architecture, lack of executive and stakeholder support, and the inability to provide a rapid return on investment.

There have been a few studies designed to examine the reason for the lack of EA to deliver rapid value. There have been no studies developed to examine the reason that EA success in some sectors have failed to translate to others.

In summary, EA stands at a crossroads. The profession of Enterprise Architecture is plagued by multiple problems.

  1. Enterprise Architecture is poorly defined by a wide array of discordant opinions, overlapping and industry-specific frameworks.
  2. Enterprise Architecture is hobbled by an inability to build momentum among Early Majority companies on the adoption curve.
  3. Enterprise Architecture has responded by focusing on the wrong set of problems: describing short-term-quick-win initiatives using methods and tools designed to produce long-term value.

Assets and services

by

What is a service? And what do services do? Seems like it’s time to re-explore some of the routine questions that come up almost every day in a service-oriented enterprise-architecture… not least because these questions are right at the core of the Enterprise Canvas model. And, in turn, the discipline and rigour about services that modelling […]

The Next Big Leap: Everything is a Business Service

by

Since the 1970s, authors like Alvin Toffler[1], Daniel Bell[2] and John Naisbitt[3] have predicted the post-industrial society. They forecast the end of the industrial era and the dominance of services and information. This is not a new message[6]; the entire service provider industry has reformed around this idea, and in the USA today non-manufacturing industries account for almost 90 percent of the economy. Virtually every product today has a service component to it and many products have been transformed into services.

One of the most interesting examples of this is the Amazon Kindle service which provides an integrated front end to a wide range of Amazon services. The Kindle service optimizes purchases of books plus access to library and new services and automatically synchronizes all the devices the user may use to access the services including the Kindle reader, smart phone and browser.

Amazon was a pioneer in use of Web services. They are well known for their internal policy of mandating that all Amazon systems functionality should be created as externalized services – that is ready for use directly by customers, and this has clearly been at the heart of their considerable success.

However few large enterprises are able to operate in such an agile manner. Amazon was built from the ground up to be an IT enabled business. In larger enterprises generally there is weaker connection between business and IT, plus the challenges of legacy application and infrastructure base and typically immature (application) service portfolios. And we can all observe the archetypical enterprise is becoming even more complex with pressing demands to respond to major market trends including mobile device based processes, analytics and real time business intelligence driven process behaviour. In this frenetic environment, how can we avoid purely tactical responses which simply generate more complexity and legacy?

CBDI suggested the answer to this problem over ten years ago. The basic service model provides an efficient and effective architecture that enables reusable capabilities that limit complexity and enable continuous change through separation of concerns. However to be truly effective the service model needs to be integrated into the entire business ecosystem where EVERYTHING IS A BUSINESS SERVICE where, like Amazon, all business capabilities are published as integral components of product and service delivery. To achieve this, the service model must be expanded way beyond the prevailing technology centric SOA approach and become an holistic business service centric model subsuming PEOPLE, PROCESS AND TECHNOLOGY.

Of course there will be decoupling between business services and software services; it will be vital that business services are formed from reusable, common software services that can be rapidly assembled into new business processes to allow rapid response to changing business needs.

Of course this all sounds very fine, but most readers will ask the key question “how do we manage the transformation to a service based enterprise?”  There are so many cultural, political, budgetary and legacy challenges that will stop such an endeavour in its tracks. Most business managers have already dismissed SOA as a technical exercise and remain focused on delivery of urgent business programs. Frankly this is THE CHALLENGE. We all read fine statements from F500 CIOs and CEOs who boast about their transformations, but in practice business as usual perpetuates conventional separation of business and IT.  We have to communicate this from the rooftops!

Some ten years ago CBDI defined a maturity model and roadmap approach that showed how SOA capability maturity moves through the stages of Early Learning, Applied, Integration, Enterprise and Ecosystem. Since then this methodology has been used by many large corporations worldwide, including notably Intel Corp[4]. In the Ecosystem maturity stage the service portfolio is integrated with business concepts and federated both internally and externally. However few enterprises have achieved this level of maturity. Amazon is a rare exception.

Many enterprises are embracing Cloud computing recognizing this architecture can introduce a critical level of virtualization and agility. In recent months there has been much interest in moving Cloud to the next level referred to as Everything as a Service (EaaS or XaaS).  HP, just one of the service providers making moves in this space defines this as “Through the cloud, everything will be delivered as a service, from computing power to business processes to personal interactions[5].” This is a very significant advance, however we need to emphasize that Cloud EaaS is a technology centric model, and there’s considerable effort required to integrate with the broader business and IT to avoid yet more legacy.

 

A first step in making this level of transformation is to establish a reference architecture that is entirely service based, spanning business and IT. Frankly existing reference architecture efforts such as TOGAF, OASIS, Zachman etc are not helpful in this area. Rather the service reference architecture needs to provide a mapping to a multiplicity of (stakeholder) views identifying key elements of pattern, standard and policy to ensure appropriate levels of consistency and governance.
Each of the views should also be documented in reference architecture, enterprise architecture, solution architecture and analytics levels of abstraction. You may be wondering why analytics? This represents a further level of cross cutting solution abstraction.
As discussed the reference and enterprise architecture views should be developed to achieve the minimum necessary level of consistency relevant to the business strategy context. 

Everything is a Business Service is the next big leap. Enterprises who have established effective SOA environments will be well positioned to make this move, but recognize it’s going to be yet more steps along a much longer journey than we CBDI articulated in our research 15 years ago.

  [1] Future Shock

  [2] The Coming of Post-Industrial Society

  [3] Megatrends

  [4] Service Oriented Architecture Demystified, Intel Press 2007

  [5] http://www.hp.com/hpinfo/initiatives/eaas/index.html

Penn State University Center for EA and FEAPO Presentation Available

by

This week I invited Dr. Brian Cameron to an internal Microsoft Architecture Summit for internal Microsoft IT Enterprise Architects and our Microsoft Services Enterprise Strategy and Architecture organizations. He was our featured keynote speaker about his efforts in the Enterprise…

Categories Uncategorized

Just Enough Detail

by

The real art of enterprise-architecture, and perhaps its hardest challenge, is in presenting the right level of detail. Not too little, not too much, but just enough. Just Enough Detail. To which people will, of course, immediately ask, “Okay, but how much detail is ‘Just Enough Detail’?”. And I’ll have to admit that there isn’t […]

Five Hurdles in Implementing EA

by

Photo credit: clappstarWhat are the hurdles organizations face when implementing Enterprise Architecture?  This is the first part of a five-part series exploring this question. Hurdle #1: Differing understanding of what EA is“Enterprise Archite…