Thread: Enterprise Architecture

Objective

If the primary objective of Enterprise Architecture is to provide a shared framework for problems and solutions at enterprise (business processes), systems (supporting functionalities), and platforms (technologies) levels, concerns and boundaries of the corresponding architectures are to be consolidated within a shared conceptual framework  that could make the whole of EA greater than the sum of its parts.

Basicam_EA_PbmsSols Click here for reading more..

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

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..