Next generation of Enterprise Architecture

Early this morning, while glancing through the latest tweets on my iphone, I was attracted by last post from Richard Veryard on slideshare:

Preamble

Good slideshow though, but since I felt that it is going a bit in many different directions, I felt that I had to react on this one, directly on my blog to reflect my own thoughts regarding: How should we deal with enterprise architecture in big companies? Richard starts his slideshow by exposing 2 historical views of Enterprise Architecture: the “Simplify and Unify” view and the “Differentiate and Integrate” view. Structuring the begining of his presentation through this split, Richard starts quickly to mention ancient approaches such as “Information Engineering” structure versus the well-known “Zachman framework“. then, he also mentions the different trends / challenges the EA is facing to… But, finally, what is the main stand-point that comes out of this presentation? To be honest, I miss a bit Richard’s stand point at the end of the presentation. So here is mine (stand-point):

My point is…

I would say that, in general, I try to learn from history and experimented people such as John Zachman and Roger Session, but at the same time, I don’t want to follow them blind. I think times change and EA has to change as well (even quicker).
To me, such approach as Zachman’s framework, which is a 198x’s vestige (see my article: Top Four Enterprise Architecture Methodologies) or trying to simplify the IS way too much, when if fact we, as Enterprise Architect must admit/deal with this complexity (up to a certain point). We (EntArch) have to make this complexity manageable and introduce enough flexibility in it to better support the business objectives.  Not saying, as I mentionned earlier that we should forget the previous frameworks or structures, but more to know them, understand their points, why they raised when they did and look at today trends/issues to make our own opinions.

Then, let’s re-invent the wheel again will you tell me… No, sorry I am not this kind. I looked for a real EA methodology for a while before finding one that suit the best to my personnal beliefs. To me, the Praxeme methodology is the EA methodology that suits the best to my personal perception of what the EA should be/do.

There I think that Praxeme is fully supporting the EA challenges Richard is pinpointing. (see fig. 1)

My Conclusion

I would quote Richard when Richard writes:

“Not suppressing complexity but managing complexity”

This is exactly what I am trying to do when practising EA. EA should not be done for the “beauty of the move”, but for the whole-of-the-enterprise sake and benefit. To add to Richard’s presentation, I would say that in order to “manage the company IS complexity and support business objectives“, we need both the theory and the practice. There,  it’s time to mention Emmanuel Kant that is underneath the Praxeme’s approach:

“Theory without practice is useless; Practice without theory is blind.“

Let’s come back to the title: “Next generation of Enterprise Architecture”. To me the next generation of Enterprise Architecture and as a consequence: Enterprise Architects :D, where I expect from myself to be a key player ( 😉 french humor) is based on a true Business approach. We, as Enterprise Architects, have to get our key business decision makers to understand the value of spending money on EA to gain money on the maintenance (IT costs), reduce the project failure rate… stop re-doing project to achieve the same goals without succeeding each time.

Once your top management is convinced, then it is time to go to work. Start from the semantic level to keep the flexibility in the whole enterprise system. Break the silos, avoid hard-coded business rules that have lead us to where historic companies are entangled in today. Complex and frozen Information System that is not anymore able to support the always moving targets of our companies, neither the economical volatilities that we are currently facing or the increasing competition (to mention a few…). Our companies have no choice to evoluate or die. This is pure evolution theory.

• If you are lucky and work for companies like Google or Apple, then you have not much to achieve in the first hand (convinced your management), mainly because the top management is already convinced and they have trusted the vision I described above. In addition, they didn’t have to manage the complexity coming from all the heritage of ages (usually called “Legacy”).
• In case you’re not working for Google or Apple, then you are even more lucky! Look at all the interesting job you have in front of you! I use to quote Booker T. Washington when saying:

“You measure the size of the accomplishment by the obstacles you had to overcome to reach your goals.”

So, let’s go to work!

How to recover the Gap between Business & IT?

Why does the Gap between Business and IT exist?

I’m sure you will find people who will try to convince you that there is no gaps between business and IT. But, I can give you my piece of advice, it’s been quite many years now that I am working in this context and I can tell you, there are gaps… I am even use call to call it a schism sometimes. But let’s look at why does this schism exist? If we want to treat it, don’t we have to identify the origin of the problem? Since we are Enterprise architect, it is always put forward that we are here to “align the business and IT”, so let’s look at the “what do we have to fill to align them”.

When it comes to improving enterprise performance via technology, IT and the business usually approach the same problem from two vastly different perspectives.  As a consequence, on one hand, business people often lack an appreciation for the IT technical ramifications of adopting a new process. On the other hand,  technology and IT teams usually find business requirements unrealistic. Of course, if both parties are unable to bridge that gap in a highly collaborative way, the consequences can be significant.

As an example, consider the scenario in which the business makes what it believes to be a simple functional request: “I just want to have this function in my application. I would make my life easier”… Then, only to hear back from IT that this request will take six months to be delivered. While it may be true that there are substantial technical implications associated with specific business requests, IT should not expect business users to understand the full impact of all the IT management details – and it isn’t necessary for them to.

How to recover the Gap between Business & IT?

Better approaches would be:

• For business, express and explain their needs, the reason why, benefits they are expecting… in two words: the Business Case (honest one, not a fake).
• For IT to focus on translating the IT management details into business language, so business can understand what IT is saying.

A trap where business is too often ended in is to ask to IT a solution that they have already decided on their own. E.g: ” “I want to have this function in my application.” Doing that is starting it all from the wrong foot and can lead the whole project to huge consequences. My own analysis of this situation is the following: this is happening mainly due to that business doesn’t can/want to spend time to explain what their are already convinced at and that the trust between business and IT is missing from the beginning. So it requires some effort from business to express their needs and not the solution they want. But they are not the only ones who need to make some efforts…

IT has to make effort on its side as well. To start with, IT has to make sure that the thought solutions are really addressing the business real need behind.  Nowadays in many companies, it is quite usal to have IT having the mission to strive for commonality in IT solutions to support different business processes to be supported by the same service or at a lower level: function. Of course, the main goal here is to reduce IT cost. So,back to my first purpose here: to analyse business’ requests and identifying already existing/future services/functions which address the same kind of need is the IT mission as well. Of course, it will take more time to do it, but it is for the sake of the entire company, isn’t it? So what few months spent in a project compare to years of savings? This has to be evaluated and time/money spent to do this evaluation must be accepted by both parties.

So, to me it is a jointly (usually called “collaborative”) work to be achieved. If both parties succeed, first to work on themselves, change their initial behavior, then to work together, I do think that they will be both on a better shape to go for a success. Once IT fully comprehends what the business is trying to accomplish, it may be able to offer an alternative approach that meets the fundamental business requirements and it would even might be done in a shorter time frame at the end.

Opening

Working together on essential business capabilities instead of implementation details, IT and business can often identify solutions that blend the two perspectives. In fact, such collaboration often enables the business to leverage what IT knows about current capabilities or best practices in other parts of the organization. It requires both points of view to ensure that the approach will enable the business to meet market demands.
Further, this type of collaboration positions IT to lead the charge in looking for solutions that are synchronized with business needs. If IT can facilitate a shift in the paradigm to a form a cooperative relationship, both sides will gain in terms of efficiency and results. Rather than responding to requests from business, IT can proactively offer solutions and alternatives. Isn’t it what we are aiming for? So called, win-win situation…

What does Business and IT alignment mean

What does Business and IT alignment mean? #iCMG Architecture World – Linkedin Group discussion http://ow.ly/39LVW

Above, is a link to a very long Linkedin discussion about:

 

Rajiv

What does Business and IT alignment mean?

The objective of this discussion is
1) Define what does IT alignment with business means?
2) Define process needed to align business and IT?
3) Define deliverables for Business and IT alignment (documents, reports, etc)?
4) Define roles and skills needed to for deliverables?

As many others, I particpated to this discussion, but since I am on my blog, here is my (short) answers:

Emeric Nectoux • What does Business and IT alignment mean?

1) Define what does IT alignment with business means?

=> I believe that in most industry (beside the IT industry… even if we could quesiton it) it is business that is steering the enterprise and not IT. So, taking this as a start point, IT is there to support business. That said, what is Business / IT alignment? Quite simple ;o), it is to make sure that what IT brings as support to business serve the Business goals. (and not the opposite 😮 )

2) Define process needed to align business and IT?

=> Here I will stand behind Fabien Villard (the previous post in the discussion list). he gave most of the answers: Agility, ability to catch and answer to the business needs at the same pace that business is changing… Focus on small changing instead of changing the whole world at once…

3) Define deliverables for Business and IT alignment (documents, reports, etc)?

=> Dude, do you want me to do your job? ;o) Look at framework and EA methods, I’m sure you will find what will make you happy in terms of deliverables!

4) Define roles and skills needed to for deliverables?

=> Skills: open-mind, business and IT skills, power play, pragmatism, high capacity of abstraction and at the same time being able to dig quickly into details = have the macro / micro view capacity…
Roles: whatever you name yourself, till you know what you’re doing.

I will be pleased to know your view as well…

Praxeme, an initiative for an open Method

---

As an introduction to Praxeme, I think the best is to read the following text which is an extract from Praxeme Institute home page:

“The majority of enterprises and organizations are confronted with the same difficulties as far as design and management are concerned: whether we consider their functioning or transformation, their processes or information systems, it is the acknowledgement of the complexity that dominates and drives to despair, everywhere.

 

Rather than respond to these difficulties in a dissipated manner, with obviously limited means, several actors have joined forces, with a view to developing an open method. Praxeme results from this pooling of investments. It is an enterprise methodology that covers all aspects of the enterprise, from strategy to deployment. One can notably find procedures and methods for the design of organizations, and processes for semantic modeling (“business” knowledge), logical architecture and services design (SOA), etc.

The contributors think that the foremost quality of a method lies in its shareability. This is why Praxeme is an open method, built in a spirit of openness. Praxeme Institute is a non-profit association, pursuant to the French law of July 1, 1901 and is depository for the corpus, guarantor of its open nature and coordinator of the works. Its site publishes the components of the method.

For an introduction, please read: the White Paper; for a more in-depth presentation: the General Guide; other guides.”

 

Enterprise Architecture or Enterprise IT Architecture?

Recently, I have been reading / discussing a lot about what people name “Enterprise Architecture”. This could be a never-end discussion, but, for the time being at least I feel like I need to make a stand point.

Lot of passionate discussions on EA networks are dealing with Enterprise Architecture and who is/should be leading it. Behind these ideological discussions, stand two very different approaches:

One which is more “conceptual” that we often call top-down approach and its mirrored: the so called bottom-up approach. I don’t want to argue about which approach is better than the other, as always, the truth is not black or white, it’s in the middle. To me, these two approaches are not conflicting, they are complementary and needed.

Then, what is the problem will you ask me? The problem is more when people say they are doing “Enterprise Architecture” while, in fact, they are performing “Enterprise IT Architecture”. Then, the situation becomes confuse and this confusion brings misunderstanding / mistrust. It is also question of people skills and background. Lot of architects have a IT background. Sometime, I feel that part of architecture profession (having a strong IT background) is trying to re-define the term “business architecture” to suit itself. This should be a term owned by the business, and business architecture has to do with money first and data second, and yet the “business architecture” defined by IT architects seldom mentions money. This is very dysfunctional.

Here is my attempt to give my vision of what “Enterprise Architecture” is and what “Enterprise IT Architecture” is.

To get the mindmap version, follow the link: http://www.biggerplate.com/viewMapImage.asp?ID=816

Enterprise Architecture

• Reporting to the CEO/MD and CIO
• Focus – Strategic
  • Working with strategic planning
  • Working closely with strategy and planning group/function.

• Unless EA has the resources to take up job of strategic plan development
• Handle both Macro / Micro views
  • Working at an enterprise level giving direction to all projects. (holistic view)
  • Working closely with PMO to provide guidance to individual projects (detail view)
• Working with the entire Enterprise
  • Working with the entire enterprise (all functions and all cross-functional process owners)
  • Business mission, business vision, business drivers, business objectives, business goals, business tactics, strategy, Customers, Products, Activities, Departments, Functions, Locations , Services, Applications, Databases, Technologies
• Working mainly at the logical level. (Projects develop the physical expressions of the logical)
• Helping in integration efforts at a logical level and avoiding redundancies in business processes, applications, data and technology, for example.
• Working with HR on motivation models
• Maintaining an EA repository/database containing information about elements of business, applications, data, and technology.
  • Able to provide gap-analysis between as-is and to-be states to help both the strategic planning and PMO
  • Able to help the management in making “informed” decisions by providing reports from the EA repository
• Making the whole organization “flexible” to “changes” as per the business/customer requirements
• Bringing the business-side closer to IT-side

Enterprise IT Architecture

• Talking only to the CIO
• Concerned with design and implementation
• Working at individual project level
• Working with project planning
• Working with the IT of the enterprise (Processes, Services, Applications, Databases, Technologies, Networks)
• Working largely at a physical level
• Working with HR on Technical role definition.
• Focus – Operational

As a conclusion (so far)

As shown on the previous mindmap, to me, both approaches are needed. If we want to categorize them, I would say that Enterprise Architecture contains Enterprise IT Architecture. But, the second one (IT) can live by itself too. It is all depend on what goals the enterprise targets. Consciousness needs to be there and conscious decision has to be taken. One should not fool the other.

Main Steps – TOGAF Architecture Development Method (ADM)

Here is a mindmap summarizing on one page TOGAF ADM – main steps.

You can also find the original file (mind manager V7 .xmap) one the following link:
http://tinyurl.com/yzzzsu3