Sunday, August 25, 2013

Reuse is the essence of building blocks in Enterprise Architecture


Would you want to buy a new hammer every time you need to drive a nail? You would soon end up with hundreds of hammers of all colors and sizes, when all you need is one!

Similarly, when creating architecture (or solution) building blocks, a clear headed focus is needed to develop and promote its reuse. It is important to agree upfront that the reason for creating a building block is to promote reuse, and not just solve the problem at hand.

For example - Lets assume that you have created a building block that brokers messages between applications and allows for easy application integration, while maintaining loose coupling. You (and your team) went all the way and evaluated various message brokers in the market, deciding to use RMB - Rajeev Message Broker! :-) It supports publish-subscribe, request-reply and a lot of other message patterns. The project team loves it as it makes their life easy. You are a hero and they throw you a party!

If you are an Enterprise Architect, the fun has barely just started. You are already thinking of proliferating the adoption of this reusable asset, this solution building block that has been created. Any other project needing similar capability does not need to buy its own hammer, err.. application integration tool. Reusing an established building block will result in faster time-to-market, lower implementation cost, lower implementation risk and higher reliability.

Remember, don't just USE.... REUSE! 

Sunday, August 11, 2013

The 'Bottomless Pit' of Current State Analysis in Enterprise Architecture!

So, how many times have we heard this, or had the urge to do this - "Lets document every process, every integration, every data element, every server, every patch, every everything - so we have a clear view of the current state. After all, don't we need to have a comprehensive understanding of current state before proceeding to the future state?"

"NO!", I humbly submit to you. There are many reasons for this, lets survey them:

[-] Losing sight of the future state - Digging into too much detail on current state sidetracks the team from the most important goal, the future state! It might output a detailed inventory of everything that we have today, which begs the question - "How important is it to define my future state?"

[-] Spending precious time and then scrambling -  I have seen it eat up much of the precious planning time while the team is left with little time to do actual future state definition and transition planning.

[-] Fatigue and loss of momentum - With old patterns, problems and sometimes excruciating pain to dig current state data, "transformation fatigue" starts to set in the team and stakeholders. The most enthusiastic time in an initiative is the beginning few weeks, it should be quickly tapped to defining a future state and transition plan from the current state. If only a high level understanding of current state is available, it is sufficient.

In summary, "just enough" analysis of current state is sufficient as you focus your team's energy in defining future state architecture and a transition plan to get there.




Sunday, August 4, 2013

The Importance of Enterprise Architecture Principles


The importance of Enterprise Architecture principles can not be overstated. With the choice of appropriate principles and consensus within your company, these can lead to amazing benefits.

Unfortunately, since these principles do not have complex diagrams, taxonomies and frameworks to support them, they seem to fall out of favor with some folks. They are often considered "fluff", "cheesy" and "stating the obvious". Lets first take a look at what these principles are:

TOGAF definition - "Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission."
(My)Translation: Guidelines that guide behavior and give us preferred practices when architecting solutions. Think of them as pre-made architecture decisions! How wonderful... lets repeat this very fundamental thing that is at the heart of coming up with principles - pre-made architecture decisions!!

Of course, each principle should describe a motivation behind it, i.e. "Why should I do this?". It should also describe what are the implications of that principle, i.e. "What do I need to do to adhere to this principle?"

Question: How many Enterprise Architecture principles should I have?
Answer: Even though it depends on your organization, I believe that 10 or less is the sweet spot. Remember, the intent of these principles is to guide behavior and give direction to your enterprise. We should be able to articulate them at the drop of a hat - if I need to reference a dictionary of EA principles, I have probably over engineered it.

The real power of these principles is in its simplicity. Lets take an example of a powerful EA principle from one of the companies I know:

Principle: Reuse
We will reuse process, data and IT assets whenever possible.
Adherence to this simple yet powerful principle ended up saving more than 10 million USD in a single technology decision alone!

Some other EA principles could be - Build vs. Buy; Use of Open Standards etc.

One important reminder - the intent here is not to police but to enable faster and smoother solutioning. Please see Enablement vs. Control post for more details.

I hope you enjoyed the post! Please continue to send me your comments and questions, I love it!

** Cartoon inspired by Groucho Marx's quote on "Principles"

Blog Archive