EA - Enterprise Architecture or Extreme Aggravation

As part of a proposal, a prospect asked us to provide the 10 most important pieces of advice for an EA team. Wow, I thought, that’s a really good question. And short of being able to do an awful lot of literature research (I am still on this assignment in the Middle East, and my library is at home back in Frankfurt), I just took a shot.

I did not manage to get together 10 guidelines, but have a look at these 4 – and please feel free to fill in with your own experience.

1. Understand the issue you are trying to address
Many EA projects are short of a clear objective - which problem to solve and which stakeholder's needs to address. This results in a lack of sponsorship, inability to measure results and to demonstrate benefits, and a general lack of direction.

The key activity when kicking of or revitalizing an EA effort is to understand the issue the organization needs to address. If it is on the path for massive growth, the organizational structure as well as the organisational assets (including IT) need to be focussed on the value streams driving the growth. In a large organizational transformation, existing assets need to be compartmentalized to enable their reconfiguration.

If it is about cost control, cost drivers need to be identified, areas and mechanisms of cost reduction need to be defined. All these changes are deeply architectural in nature.

Identifying these core objectives allows getting the right stakeholders on board and enlisting their backing by aligning with their needs (well, in the end with their KPIs and incentives). Without them, EA is just another J2EE – a pure technicality without any relevance for the performance of the organization.

2. Organizational Transformation is not an IT issue
While architectural practices and architectural approaches are often driven out of the CIO's organization, they are not a matter of IT. Enterprise Architecture – in the sense of "Architecture of the Enterprise" – is about the way the organization leverages its assets to orchestrate its value chains, how it uses them to build a platform for execution. It is about enabling well-understood segments of variability which link into the core execution infrastructure to create organizational leverage and scale, and to execute on unique value propositions quickly. EA also helps identifying transactional utility services which are opportunities for out- or insourcing - strengthening organizational focus or creating business opportunities.

Building such a platform for execution is a massive organizational transformation initiative. IT can help structuring it; but executing and managing the change is a task of the organization as a whole.

3. Get the right stakeholders on board for the scope you are trying to address
There is no point making architectural decisions if the changes implied are outside the project's circle of influence. Therefore, the project needs to engage stakeholders who have the money, the resources and the influence to make things happen.

The only way of achieving this is to understand the (visible and hidden) objectives of stakeholders in the right power centres of the organization, and to map out how you are going to address their needs. A powerful tool is to align with an existing strategy map, as the objectives there are already agreed between a large number of stakeholders.

4. Communicate, communicate, communicate
Enterprise Architecture has a huge spectrum of stakeholders, most of them outside IT. Engaging them means passing targeted messages through the right – formal and informal – channels. It also means communicating continuously, and providing information both in pull and push mode.
This requires marketing techniques, an area many Enterprise Architects tend not to very well-versed in. So the Marketing and Communications department is their natural partner in these efforts. If there is an internal communications group, great - it will even have the channels and infrastructure. Otherwise, it will have people who can at least help defining how to address the organization.
So, as I mentioned before – feel free to share your advice. I am still 6 topics short from my original target…

Kind Regards from the really, really sunny Middle East
Thomas Obitz

Posted by Thomas Obitz at 10:58 AM | Permalink | Comments (1) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Swades and the lessons it held for Architects about giving back in the form of teaching budding architects, publishing papers etc.

The 300 Spartans (Year of Release: 1962; Director: Rudolph Mate; Our Architect: King Leonidas, played by Richard Egan; Architect's Character: The Greek king of Sparta who is up against a stronger Persian army)

‘The 300 Spartans’ depicts the invasion of Greece by the Persian army and the role of King Leonidas, the king of Sparta, known for its proud, bold and courageous army. The story deals with a number of issues – the role of the senate, the mammoth scale of problem at hand and the values of a team, in this case of a state.

The legend is that King Leonidas, prohibited to use his army to fight against the Persians by his own Senate members, decides to take on the swarm of Persian army with 300 of his body guards. His force not only holds the Persian army at bay in a long drawn battle but also ignites the values of the rest of the Greeks who decide to launch an all out war against the Persians. This movie was remade in 2006 under the name ‘300’.

 The lessons that this movie offers for architects are:
•    Doing the right thing – aligned with our own personal and moral values.
•    Courage under fire
•    Setting an example to ignite other minds.
•    Persistence
•    Looking for alternatives
•    Attitude!

For this movie too, I will skip talking about any specific scenes because it makes its point through the whole storyboard. There are a lot of lessons that we, as architects, can pick up from this movie. The most important one being – develop the right attitude and use it! The second most important thought that this movie provokes is to introspect ourselves to see what are we made of? What are our values and how do we prioritize them.

Values are something that take the form of our signature in all our work. You can tell from the work of an architect that he places higher premium on technology than on business, or if he confronts issues vs. sweeping them under the carpet.  Values form the torch light which show us the way when all other light is swept away. They can push us to do the right thing and doing the things right.

Posted by Guest Author at 09:40 AM | Permalink | Comments (0) | TrackBacks (0)

As I sit down to blog for the first time on the Enterprise Architecture blogs, a very fundamental question crosses my mind.  That is how do architects speak, or communicate in general.

 A very common occurance is to use a lot of buzzwords.  I once encountered an architect who said "issue A and issue B are orthagonal".  He meant A and B are independent of each other.  Architecture patterns too - be they singletons or facades - can be confusing explanations to IT management and customers.

The main issue I wish to raise is that does our language need to be so threatening to outsiders.  No wonder many times architects are described as out of touch or too abstract.

My experience is that messages to people outside the architecture community need to be in simple language.  Business executives who often are sponsors of IT work, and hence of architecture projects, business operations managers, IT project managers are all interested in understanding the recommended course of action and the rationale for it.

While the rigour of architecture formulations is a necessity, very often architects use complex language to impress each other.  Over a long period of enterprise architecture engagements, I have settled on simple and clear working and final deliverables that do not require translation before being tabled to the stakeholders

I will like to know your experience.  What parts of the architecture speak, in your opiniion, are complex by necessity and need the relevant rigorous terminology?  Do you or people you work with use long words just to impress each other?  Or, as in the words of my above mentioned architect friend, need and practice are othagonal to each other?

See you around.

Rajeev Arora

 Melbourne. Australia

Posted by Rajeev Arora at 03:05 AM | Permalink | Comments (0) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Padosan and the lessons it held for Architects about observation, analyzing the non-obvious, taking care of your team, knowing your priorities etc.

Swades (Year of Release: 2004; Director: Ashutosh Gowarikar; Our Architect: Mohan Bhargav, played by Shahrukh Khan; Architect's Character: A Music Director by profession, US-based research scientist with NASA, of Indian origin).

‘Swades’ is a story of Mohan Bhargav, a research scientist with NASA. He has Indian origin but is settled in the US with a nice job and comforts of life. He makes a trip to India to see his grandmother when leads him to a village. During this trip, he gets a firsthand experience of life in rural India and how far behind they have been left from the ‘progress’ made by towns of the world.

As a first project, Mohan helps a bunch of villagers set up an electricity generating unit. Subsequently, he decides to move back to India for good and dedicate his life for the advancement of rural India.

There are three important lessons that this movie can teach architects:
•    Giveback
•    Giveback
•    Giveback

I will refrain from going into the specifics of a few scenes for this movie, as the message is spread across the whole movie in bits and pieces.

As architects, we often forget to take a breather and give something back to our community, to our industry which has given us the fabulous opportunity to work and make living doing the stuff that we love enough to do for free.

At the end of every year, an architect should measure his/her success by the number of things he/she has given back in that year. The 'giveback' can take form of a class that you taught to budding architects, a paper that you published based on your experience to spread your knowledge or a novel item that you invented to aid the industry.

Posted by Guest Author at 12:45 PM | Permalink | Comments (0) | TrackBacks (0)

- Mohan Babu K (cross posted from the Managing Offshore IT blog)

In my previous post, I talked about the extending role of Enterprise Architects at services firms into Marchitects. This ‘selling’ of architecture services is no different from what our peers in client organizations undertake too.

Enterprise Architects, many of whom report into a CIO/CTO organization are also under continual pressure to ensure that the organization derives an optimal ROI from their IT investments, which means they need to ‘sell’ the value of robust, scalable architecture, planning and roadmaps to their stakeholders, some of whom may be focused on the tactical: ensuring that the quarterly targets are met, budgets balanced and operational challenges addressed. Even the ‘strategic’ focus may sometime involve reacting to external trends (read between the lines: it is the economy, slowdown etc)

But back to the challenge of selling that Enterprise Architects at service firms face:

• Thinking beyond revenue and dollars: Most service firms aspire to move up the proverbial ‘Value Chain.’ And when it comes to technology services, what better value chain than consulting with client CxOs on their Enterprise Architecture? However, this ‘move up value chain’ is not as simple, or even sexy as it sounds. Why? Because sales teams at services firms are geared towards (and rewarded for) ‘downstream’ and ‘incremental revenue.’ The challenge is that when consultants work with clients on their EA strategies and roadmaps, they shouldn’t - and generally don’t - have downstream-dollar-signs in their eyes…. which doesn’t always please internal sales teams. [footnote: taking this high-road is not always practical since reward (and bonus) structures for individuals, including architects at service firms are geared towards meeting unit, group and organizational numbers.] 
• Being unbiased while recommending solutions: Another challenge consultants, especially from larger services firms face is while recommending solutions and technology options to clients. Architecture consultants from a product vendor organization may have their account teams tacitly leaning on them. The reason is not hard to find: most service firms have their proprietary solutions, frameworks and toolkits for myriad technologies. Consulting organizations make considerable investments in developing such solutions and the ROI can be derived only when sold/deployed by clients. There are times when these toolkits and products may be an ideal fit for a client need; but not always. Consulting Enterprise Architects need to be unbiased and be willing to push back their Account management teams when need arises. [Again, taking the high-road may come at a personal cost: internal bonuses and incentives]

Clients have an opportunity (and perhaps responsibility) to ensure that the high-end consultants they engage continually provide unbiased inputs. In a sense, the challenge faced by consulting Enterprise Architects is an opportunity to you, the client. You can efficiently leverage their ideation, selling, persuasion and presentation skills to help your internal Enterprise Architects and CXOs sell the ideas and strategies to your businesses and stakeholders. By doing so, you let consultants gain the privilege of being trusted advisors, which in some cases may lead to additional downstream and business for their firms.

Posted by Guest Author at 11:27 AM | Permalink | Comments (0) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Remember the Titans and the lessons it held for Architects about leadership, change, how to get people from diverse backgrounds to work together etc.

Padosan (Year of Release: 1968; Director: Jyoti Swaroop; Our Architect: Guru, played by Kishore Kumar; Architect's Character: A Music Director by profession, Guru always has a solution for all problems and never lacks innovation)

This is one of my favorite movies. It is witty, sharp and outrageously comic. Our architect is the character of Guru (Vidyapathi) played by the legendary Kishore Kumar. Guru has a flock of 4 friends that he is really close to and is always available to them in the role of an advisor, a psychiatrist and above all a friend. He has solution for almost every problem that you can throw at him. Most of his solution look awkward, but they all work beautifully! The outline of this movie is how Guru helps his friend, Bhola (played by Sunil Dutt), who has no knowledge of music, to capture the heart of a dame, Bindu (played by Saira Banu), who is obsessed with music.

There are a lot of things that an architect can learn from this movie. A few worth mentioning are:
•    Never say die!
•    Keen Observation
•    Analyze the non-obvious
•    Take care of your team, your mentees, be there for them.
•    Know your priorities

Scenes to watch for:
1.    There is a scene in the middle of the movie, where the whole gang tries to spy on Bindu and her music teacher – Master Pillai (played by Mehmood). While spying, most of the other members of the team are obsessed by how beautiful Bindu looks and some are totally angry with Master Pillai for his bold movies. While all this is happening around him, Guru, using his keen observation skill analyzes that in reality, Bindu has no liking for the teacher per se, instead, she is fascinated by his musical talent and respects him for that. This single observation shapes up the remainder of the movie and becomes the key instrument in getting Bhola, his life’s love.

Although it sounds very simple, but keen observation is a very rare skill. Unfortunately, it is also one of those skills that you cannot pick up in a class. You need to practice it by opening your mind and trying to look beyond the obvious. The architects who master this skill are automatically promoted to a different league than their competition. They have long lists of satisfied clients and are up to their neck with repeat business.

2.    At one point during the movie, when Bhola loses faith in Guru’s strategy and approach, he grows dull and erratic. In this scene, Guru cheers him up by pointing out the silver lining and giving him a projection of what future could hold. At the same time, he also addresses his immediate concern by justifying his approach and elaborating on why he is doing things the way he is doing it.

It is a very common problem with us as Architects. We usually get carried away with the details of the technology and assume that our team and the people sitting across the table understand the reasons and rationale, right? Wrong! It is quite important for you as an architect to explain your decisions to the people around you – in the form of architectural decisions documentation or one-on-one discussions - whatever works. The flip side of this aspect is that if your team does not understand why a decision has been made, they will not be able to sell it on your behalf to others. In fact, it can also happen that they come back from meeting convinced that the decision that you have made is wrong. And the problem keeps on snowballing …

3.    In general, throughout the movie you will notice that our architect never gives up. He is always on the lookout for alternatives, for other things that may click … for a plan B. During the first half of the movie, upon learning of Bindu’s fascination of music, Guru tries to teach Bhola the fine art of music.  After failing miserably at that, he comes to terms with the fact this approach is not going to work and let’s go of the approach. While he is pondering over what to do next, his mind picks up the faint sound of a radio playing at a distance. One thing leads to another and not a long time after, he decides to work with Bhola as his playback singer. A pure, master stroke of genius!

This scene can teach us the value of keeping our eyes, ears and mind open. The next big idea can come from anywhere and at any time. There are lots of corollaries available outside the technology world which can give us insights into how to tackle the most complex of IT issues. Another important lesson in this scene is to understand and appreciate different talents available in your team and come up with ingenious ways on how to put them to best use. You have dead weights in your team only because you have given up on figuring out how best to use the skills available.

Posted by Guest Author at 09:22 AM | Permalink | Comments (3) | TrackBacks (0)

- Mohan Babu K (cross posted from the Managing Offshore IT blog)

While reading Andrew Manning’s blog entry on “Enterprise Architects: Time for more job titles?”  I began thinking about a barbeque I attended at a friend's place few weeks ago where colleagues and peers had gathered. It was interesting to observe that folks who had gathered were finding it hard to pick on neutral topics beyond the day’s weather and the difficulty in maintaining the lawn, using the host’s backyard as a case-in-point. It was not hard to see why.  A few were from the ‘sales’ side of our business – account managers, engagement leaders and the like – and others from the consulting side - IT architects and consultants. And not surprisingly, it was the few Marchitectects in our midstwho were trying to find an icebreaker.

Going back to Andrew’s list, I guess, one title, I would add is Enterprise Marchitects: folks at service firms who act as a bridge between sales and consulting. The “Enterprise Architects” at service firms - many of whom are also Marchitects -  have a distinct role to play in the industry. The role also comes with its share of challenges for obvious reasons:

• Consulting Architects are generally sought ought in the industry and are well compensated, because of which their services also command premium/higher billing rates. From a software services context, it also means that Architects can add to a significant ‘cost’ component of a typical project. Cognizant of client’s cost constraints, the some Account Managers are more comfortable underselling the need for an architect to ensure a bigger pie of rest of the project rather than translate ‘cost’ to demonstrate ‘value.’ This means the architect, who is already under pressure to be continually ‘billable’ also has to juggle the hat of a Marchitect
• Architects also need to accept the fact that though they bring a specialized/niche skill to the table, they are still considered as ‘resources,’  both to a firm’s own sales folks and of course to client’s FTEs and program stakeholders who naturally look at external consultants as hired-guns.
• Another Marchitecture dimension is to juggle the buzz from internal and external spin doctors. Those of us who have been in the industry long enough know what I mean by spin doctors: folks who can take archaic sounding acronyms coined by industry analysts, visualize a few possible ‘scenarios’ and ‘solutions’ and start preaching it to clients, all with the conviction of a convert.

Enterprise Architects with service firms juggle the above challenges, along with their day-jobs of helping clients architect robust, scalable technology and business solutions. Which brings us back to where I started: the delicate balance between Architecting business and technology solutions - which architects are skilled at – and the business of architecting technology solutions (read ‘selling’ architecture as a service) which is a skill Architects try to acquire. Now, this yin-yang has another dimension to it: measuring the ‘value’ that a consulting Enterprise Architect/Marchitect brings to the table. …

I will continue the line of thinking in my next post

Posted by Guest Author at 11:25 AM | Permalink | Comments (0) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Lagaan and the lessons it held for Architects about selling ideas, negotiations, leading change etc.

‘Remember the Titans’ (Year of Release: 2000; Director: Boaz Yakin; Our Architect: Coach Boone, played by Denzel Washington; Architect's Character: Chief Coach of the first mixed race football team) is set against the time of segregation. Then the Government abolished segregated schools and gave the right to all students to enroll in any school. The movie focuses on one such school - T C Williams High School in Virginia which has been educating white students but has now opened up to black students too. There is an atmosphere of tension and apprehension on all sides. In the midst of all this turmoil, Coach Boone lands up as the head coach of the school’s new football team.

Even in the game of football, there is a lot of resistance from both the sides to come together. Coach Boone leads the team to look beyond the color of their skin and teaches them to function as one integrated unit. This movie is based on a true story and the team that the coach put together went all the way to win the high school championship in its first year.

The lessons that an architect can learn from this movie are:
•    Leadership Qualities
•    Acting as Change Agents
•    How to get people of diverse values & backgrounds to come together as a team
•    Maturity to appreciate when usual rules do not apply
•    Improvisation

Scenes to watch for:
1. There is a scene during the initial rounds of practice when a black team mate is confronted by the captain, who happens to be white, on how he is not playing for the team. The captain goes on to describe this player as a waste of God gifted talent and criticizes his attitude. To this, the black player replies – “Attitude reflects the leadership, Captain.” He further substantiates his statement by pointing out how some of the white players are not playing the game in the correct spirit, right under the captain’s nose and how that does not bother him.

This is one big, big take away from this movie. In our world too, attitude of the team that we are working with reflects the attitude and approach of the leader. This particular scene teaches us the value of being fair, treating every team member with respect and impartially. It also emphasizes the importance of seeking feedback from the juniors who work with you directly. This can happen informally, over a cup of coffee or a beer. What differentiates a good architect from a great architect is the latter’s ability to be open to criticism and adaptability to change.

2. After the end of a very trying training camp which lasts for a few weeks, Coach Boone congratulates the selected team by saying – “I am not going to talk to you about winning or losing. You are all winners in my book already. Because you did not kill each other at the camp”.

The very simple gesture of appreciation can go a long way in boosting your team’s morale. And yet, we don’t see it happening as often as it should. This is doubly true for high risk, high stake projects because everyone gets so engrossed in the day to day work that there is hardly any time for appreciation. Regardless of the nature and complexity of the project that you work on, do remember that you are working with people; people, who are not machines. Appreciation is a nice gesture that should be displayed whenever the opportunity arises. For complex projects you should list it as a to-do item in your task list to look for opportunities for appreciation the same way you find out time for reviews.

3. In the concluding scene of the movie, there is a dialogue by one of the coach’s daughters – “People say that it can't work - black, white. Here we make it work every day. We still have our disagreements, of course, but before we reach for hate, always, always, we remember the Titans.” That, kind of, sums it all up!

Gives you a true picture of how team with diverse backgrounds can come together and achieve wonders under the architect’s leadership. Need I say more?

Posted by Guest Author at 07:58 AM | Permalink | Comments (0) | TrackBacks (0)

Gartner recently published their June 2008 Magic Quadrant for Enterprise Architecture (EA) tools. (See http://www.gartner.com/DisplayDocument?id=697707&ref=g_sitelink (registration required); or a free version at http://www.troux.com/company/news/pressrelease.asp?pr=080618_gartnermq_pr.xml).

A couple of things sprang to mind as I skimmed through the report:

Tools are rarely the main reason for unsuccessful EA activities. There's the commonly quoted phrase "a fool with a tool is still a fool" (and can add "a fool with a tool can do more damage more quickly").

The same is true for the Gartner Magic Quadrants. As a tool they can be misused, intentionally or not. The report has a specific scope, focussing on the modelling and repository aspects of the tools (and to some extent publication) as well as supplier capabilities. It's easy to be lulled into thinking that tool X is better than tool Y (even if it is only at a high level). But this ignores a number of other dimensions such as: the tool's ability to support different levels of organisational capability; how likely it is to be adopted by different user communities; how well it supports 'getting stuff used'...
 
Personally, I like the Gartner 'Magic Quadrants' . They're handy for showing people an overview of the main players (selected by Gartner, and less useful if there is something you want to promote that doesn't rank highly). The quadrants have a reassuring, semi-quantitative feel. And, they indicate 'ability to execute' vs. 'vision'. Surely not much more that people developing EA roadmaps need!?..
 
However, for many organisations mandating one tool is not the answer to successful EA. An EA tool portfolio and roadmap can allow different people and material to be brought into the 'fold' and provide a basis for integration. (This is where EA metamodels start to become handy, as well as adoption of standard modelling notations such as BPMN). There are several Enterprise Architectural maturity assessments around. Looking at the tooling needs for the different dimensions being assessed is one way of identifying tool requirements and priorities.  
 
A couple of specific thoughts on the report:
 
It'll be interesting to see how IBM takes forward the Telelogic suite (and the access it now has to EA groups in various companies). And also how it deals with the potential synergies/overlaps/duplication between various modelling products such as System Architect, Rational Rose, Tau Modeller ... as well the requirements management tools (Requisite Pro and DOORS, though the latter has quite a mature following in the government and defence areas).  
 
SAP: Aris (IDS Scheer) and Mega are still tempting for organisations with large SAP investments.
 
Microsoft isn't listed specifically (always interesting to see how Enterprise Architects react when you mention Visio). Visio is not a 'proper/traditional' enterprise architecture tool. However, many organisations do have models in Visio and most of the more sophisticated tools will support Visio import (and in some instances export)  eg System Architect's improved Visio import capability makes it easier to leverage some of that existing collateral. Over the next few years, as Microsoft's "Oslo" takes shape; as the gap between design and implementation reduces, it will be interesting to see how things change. Portals (eg SharePoint and Visio 2007 +) will provide many organisations with a way of quickly providing interaction/discussion around models - outside of the traditional EA group.
 
Perhaps surprisingly (or not), there is no explicit reference to SOA in this EA tool assessment. Many of the tool vendors listed do provide SOA support linked into the broader EA capability to varying degrees.
 
Irrespective of what people think of the content of the Gartner EA tool Magic Quadrant many "decision makers" will look at this when considering tools and that is sufficient reason to at least skim the report.
 
Andrew
 
(As an example of a set of detailed EA tool features see http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v4.2.pdf )

Posted by Andrew Manning at 11:53 AM | Permalink | Comments (2) | TrackBacks (0)