Enterprise Architecture: Don’t Be a Fool with a Tool

Last month I referred to the cult comedy Office Space when I posed the question, Is Enterprise Architecture Completely Broken? After speaking with two authorities on The Open Group Architecture Framework (TOGAF), perhaps I had the wrong film. A better choice: Monty Python and the Holy Grail. Apparently, Enterprise Architecture is not dead yet.

In fact, TOGAF is perhaps the most popular Enterprise Architecture (EA) framework today, and its popularity is only increasing, in spite of the fact that many organizations misapply TOGAF. Yet, even for those organizations that successfully leverage TOGAF and thus achieve positive business outcomes, business agility is still largely out of reach. Thus, while Agile Enterprise Architecture may have crossed the chasm, TOGAF has yet to make the leap.

Agile Enterprise Architecture Finally Crosses the Chasm

In my first article for Forbes, I asked whether Enterprise Architecture (EA) was completely broken. My conclusion: executives seeking digital transformations of their organizations require a more agile approach to architecture than traditional EA has been able to offer. Instead, architects must treat the enterprise itself as a complex system, driving business agility as an emergent property of the organization as a whole.

Perhaps the best example of a company that has succeeded with this agile approach to architecture is Netflix. Netflix NFLX +0.6% is well-known in technology circles for its industry-leading use of Public Cloud, but how they build software and in particular, how they drive their overall architecture are perhaps the most paradigm-shifting aspects of their accomplishments.

Climbing the ladder from EITA to EA

One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem.  Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.”  The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect.  Building those relationships and that credibility takes time… sometimes many years.  Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.

I call this “climbing the ladder” from EITA to EA.

Ten Ways to Kill An Enterprise Architecture Practice

Have you seen practices that you know could kill an Enterprise Architecture practice?  I have.  A recent LinkedIn thread asked for examples, and I came up with my top ten.  I’d love to hear your additions to the list.

How to screw up an EA practice

  1. Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
  2. Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture.
  3. Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
  4. Get everyone trained on a “shell framework” like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
  5. Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
  6. Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
  7. Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
  8. Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
  9. Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
  10. Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.

Source : http://blogs.msdn.com/b/nickmalik/archive/2013/09/05/ten-ways-to-kill-an-enterprise-architecture-practice.aspx

Bankacılıkta Yeni Trendler

Bankacılık sektörünün usta isimlerinden Brett King tarafından yayınlanan ve önümüzdeki on yıl içerisinde, sektörde beklenen trendleri görebileceğimiz çalışmaya göz atmakta fayda var.

Benim en çok ilgimi çeken “Hyper connected customers” oldu. Bu yaklaşım; perakende ve telekom başta olmak üzere, diğer sektörleri de mutlaka etkileyecektir.

Next Decade Banking Trends

Enterprise Architecture Certifications Distilled

Year after year I am finding that Enterprise Architecture certifications are becoming more important to architects. Back in 2007, I remember reading an article from Gene Leganza called, “Is EA Certification Important?”. In that article he stated that 65% of the people he had surveyed stated that EA certification is not important but he also noted that a significant minority stated they were including EA certification criteria in their hiring processes.
Click here for reading more..

SOA? ESB? What is all this?

Lots of nice articles have been published on the net on both Service Oriented Architecture (SOA) and Enterprise Server Bus (ESB). This topic is being discussed quite heavily for last few years but started gaining weight as ESBs started getting more and more matured. To start this series, I am planning to put together information which I found to be very useful when I started working on this project. Some of this information has come from other blogs, company websites (JBOSS, IBM, Cape Clear, BEA, Microsoft etc.). I am planning to add my experiences when we carried out performance analysis of one of the ESB implementations.

A Day in the life of an Enterprise Architect

Enterprise architecture has grown from being just a set of small pilots to being a fully sponsored and supported initiative within enterprises. With the growing demands to reduce costs, increase agility, and standardize IT environments, there has been a surge of enterprise architecture activity. According to Gartner and the MIT institute the growing complexities that span across process, information and software are among the three top CIO concerns. Additional pressures come from regulatory bodies that impose compliance guidelines on the industry (such as the Clinger-Cohen Act of 1996 or FFIEC Guidance). Compliance has been a catalyst for the formation of an enterprise architecture practice. This article will walk you through the daily challenges that an enterprise architect faces. By doing so, we hope to provide a unique perspective on this growing role in the IT industry.

A Comparison of the Top Four Enterprise-Architecture Methodologies

Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field initially began to address two problems:

  • System complexity—Organizations were spending more and more money building IT systems; and
  • Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.

The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased.

Today’s bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic.

Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

  • The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
  • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
  • The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
  • The Gartner Methodology—Can be best described as an enterprise architectural practice