I have been consulting with a client’s Enterprise Architecture team and got around to reflect on questions that I have been asked in other contexts: Who are SAP Enterprise Architects? What (if anything) is different about Enterprise Architecture in a product/ERP landscape?

The client, lets call it MyCorp, is a multi-billion dollar global manufacturing company with a few core lines of businesses. The business and IT operations are managed by geographic units for Latin America, North America, Europe and Rest of the World. MyCorp`s IT is supported by a federated team of Enterprise Architects . As with most multinationals, MyCorp has several “key” ongoing technology and transformational initiatives that the Enterprise Architects are supporting. So what is unique about MyCorp`s Enterprise Architecture focus? Besides the fact that every organization is “unique,” this happens to be a “SAP Shop.” Which is to say the IT application landscape is predominantly a mix of SAP tools and technologies and in pockets where it is not, there is a roadmap to move towards this direction.

For organizations like MyCorp, The operational “sustain” challenges typically include

• Product versioning, licensing support. This may involve working closely with the operational managers and ERP vendor`s (SAP's account management?) teams.
• Operational governance and platform management: Would include tracking the SAP system ID (SID).. Especially around upgrade paths for individual tools and platforms.
• Technology, platform upgrades: Includes reconciling ECC, Netweaver, Enterprise-Packs, Service-Packs etc from SAP's roadmap to what's in the enterprise landscape. For example the article in netweavermagazine talks about: By now, every licensed SAP organization should be aware of the inevitable upgrade from SAP R/3 to SAP ERP Central Component (SAP ECC). Every every licensed SAP organization is probably aware. But what does an individual roadmap for upgrade look like? 
• Integration: This includes intricacies of SAP`s PI stack, emerging thought leadership in netweaver and other integration platforms. Organizational drivers may also weigh in: is the goal to move towards a uniform integration platform, or will MyCorp`s IT have to support more than one Integration platform . . . for Business-to-Business, Business-to-Consumer, System-to-System and other integration requirements? Or for that matter, what does SOA mean in the context of MyCorp`s Business strategy?

In the context of Enterprise Architecture at companies like MyCorp, if we can use the term “innovate” loosely, it would include:

• Supporting Transformational initiatives: This includes technology lead innovations, helping business, business units take new tools/services/products to market or even helping large initatives go-live faster-and-cheaper using automation, reducing effort, leveraging other efficiencies. etc etc.
• Business Architecture: In this context, the scope of Business Architecture may go much beyond just thinking of business processes and requirements; and would include leading the preparation of business cases, justifying ROI, reducing long term TCO, justifying the value of IT among others
• Structured Thinking and Best Practices: Another typical Enterprise Architecture activity at organizations like MyCorp is to ensure that they are leveraging the right tools and frameworks. For example, if one were to bring in a TOGAF perspective: Some of the thinking from SAP Enterprise Architecture Framework (EAF) that has fed into the TOGAF 9 thinking, may be leveraged. [Ref: SAP Enterprise Architecture Framework Unveiled: Aligning IT to the Business]

An interesting aspect of SAP landscapes, given the legacy of large ERP rollouts is the clear separation-of-concerns that exists between the Technical and Functional consultant roles. (re: SAP Functional Consultant Vs SAP Technical Consultant). Why is this interesting? At the risk of generalizing, I find that many of the Enterprise Architects in the ERP space come from the ranks of Technical consultants (say ABAP programmers), just like many Enterprise Architects in the non-ERP space spent time in the trenches programming. Given the structured business vocabulary, enforced by ERPs platforms, the EA`s who spent time in consulting / configuring / programming in such landscape perhaps have an edge when it comes to the vocabulary and taxonomies, giving  a distinct advantage while talking to “business users” (say financial analysts or HR managers). Knowing the trade jargon, and acronyms for product lines which is unique to the product space certainly helps. This is not a challenge unique to ERP Shops alone. In other business verticals, and technical environments, one would have to juggle with other technical, product and system acronyms too.  

Reading thus far you are probably beginning to wonder what`s unique about EA in an ERP or product-centric-landscape? An Enterprise Architect with a sprinkling of gray hair (like me) you are probably musing: not much! Going back to the Day-in-life of EA, the depth in ERPs is a distinct advantage when it comes to supporting the operational and “sustain” challenges, say, negotiating with product/ERP vendor teams. However, when it comes to mapping application and system landscapes, understanding the IT spend, defining future state roadmaps, ensuring alignment with business strategies etc, the breadth of expertise in the Enterprise Architecture value chain becomes more significant.

- Mohan 

Footnote:

* For this discussion, I focus on SAP/ERP "Enterprise Architects", and not SAP Architects. As should be obvious, I am using the ERP product SAP that happened to be the platform-of-choice at MyCorp. With all the consolidations, buyouts, M&A`s among software vendors, I guess the other "large" ERP that remains is Oracle? . . I will reserve the debate on ERPs for another time and another blog

In my previous EA blog entry, I had written about contextualizing Infosys’ Enterprise Architecture survey findings. Since then I had an opportunity to observe and reflect on an aspect of the survey: adoption – and challenges - of Enterprise Architecture Tool at a Global 500 enterprise. To set the context for the discussion, a brief extract from the survey report as it pertains to adoption of EA tools:

• There is an increased adoption of EA tools, but there is no product which has managed to dominate the market
• The EA tools market is fragmented with the vast majority of respondents claiming to use general office and collaboration tools and drawing tools (e.g. Microsoft Visio) for Enterprise Architecture Modeling

This should not surprise many of us in the industry!

• Create and manage models of the Enterprise Architecture
• Support Business Architecture requirements (BPMN, BPML etc)
• Maintain traceability among elements of the EA
• Publish standards and manage exceptions to standards
• Manage requirements
• Manage the existing portfolio of systems (the EA realized)
• Manage requests for architecture work
• Track changes to the Enterprise Architecture
• Communicate the Enterprise Architecture to multiple audiences
• Publish policies, principles, procedures and methods
• Report on the Enterprise Architecture to management
• Allow architects and managers to simulate the effects of change

Here one can easily see the makings of a Swiss Army Knife. And to think one of the key goals of Enterprise Architectures is to ensure K.I.S.S of an enterprise portfolio! The market demand being what it is (or I must say was), tool vendors have only been too happy to oblige; adding a few more bells and whistles to an already bulging requirements wish-list.

How do you ensure that an Enterprise Architecture tool that is designed to be a Swiss Army knife, and already licensed/procured by the organization be used efficiently for just a few key requirements? Well, this just creates opportunities for Enterprise architecture consultants, self included (Or in other words cost and effort that can be mitigated by restricting requirements to a few key areas)

Back to the case of the EA team at the Global 500 enterprise that I am working with. The client had already licensed an Enterprise Architecture tool (let`s call it Tool-A) and the EA team has been modelling with it sporadically. My charter was simple: observe and analyze usage of the tool and propose a way forward. After reviews, deliberations and interviews with stakeholders, I realized that the EA tool requirements were rather straightforward: 

• Modelling logical views of a few architecturally significant areas of the Enterprise portfolio
• Modelling logical architecture to facilitate communication in transformational program/s
• Communicate the Enterprise Architecture to multiple audiences

The first two are candidates for the Tool-A and the third is best done by a simple intranet portal.

Just as we began getting warmed up on the modelling front, the team realized that another group of Business Analysts (Business Architects?) in the organization has already decided to leverage another tool (Tool-B). The primary intent of that exercise is to capture key as-is Business Processes. It is interesting that both Tool-A and Tool-B have the equivalent of swiss-army-knife-like capability (basic modelling, BPM, UML et al). That exercise is being supported by (yet) another group of consultants. And the saga continues (or should I say, has just begun)

 I couldn’t agree more with Andrew Manning who blogged on EA tools here sometime ago
- Mohan

Ps: If you can’t read the text in the diagrams, you may download a copy of the survey report

######

Dear All
Some of you may have participated in the Infosys’ Enterprise Architecture Survey 2008/2009. Attached is a soft-copy of the survey findings.

• Frameworks and Tools are helping to professionalize the EA function (Section 6)
• Emerging TOGAF thinking among architects in this is in line with the trend observed. This year respondents indicated that TOGAF has passed Zachman in terms of overall adoption ratio (32% vs 25%). (Section 6.1)
• Organizations start using architectural approaches beyond IT (section 3.2)
  1       Enterprise Architects are accepted advisors – even outside IT  (section 3.2)
  2       A separate (EA) budget gives independence (Section 3.5)
  3       EA focuses on business and information, and is a key contributor to IT Strategy (Section 4)

We can schedule some time to discuss the survey findings in the context of this group‘s emerging  Enterprise Architecture thinking.

Infosys account managers should be able to procure printed copies of the report too. A copy of the survey can also be downloaded from the Web (registration required. URL: http://www.infosys.com/IT-Services/architecture-services/ea-survey/)

Please feel free to ping back with your comments and also circulate among others who may be interested         
Regards
Mohan

Now, I am not an architect myself but I have had the good fortune of working with some really great architects and along the way, a bit of architecture knowledge has rubbed off on my seemingly non-technical mind. After we concluded that discussion, a few things kept coming to my mind:

1. How complex can a complex architecture get?
2. What makes architecture complex?
3. Should architecture be complex at all?

The few complex projects I have worked on, had really huge architecture documents, multiple architects in the team, involved multiple products and had taken a really long time to create the architecture. Based on my experience, I think these are the few attributes that define complexity of the architecture:

a) Number of products involved.
b) Number of interfaces and integration points.
c) Duration and effort involved in creating the architecture.
d) Number of architects involved.
e) Lot more things …

But then, when I look at the other side of the coin, I cannot help but think, ‘Isn’t it an architect’s job to take a complex problem and split it into simpler, more manageable units? And if that’s the case, should a good architecture really be complex? Moreover, when the designer picks up the architecture, should he be looking at a complex set of information that needs to be decoded before breaking it into simpler design details?

I have gone through the architecture documents of some really complex projects and what I appreciate about them is the simplicity. The documents, no doubt, had been extremely huge, but the language, the flow of thoughts and the explanation had been very simple and easy to understand.

In my humble opinion, a really great architecture is one that is not complex. In fact, there is no term as a “complex architecture” or a “complex architecture” is a synonym for a “bad architecture”.  What is “complex” is not usually the architecture in itself; but the whole process of architecting. In most cases the “technology challenges” and more of “people issues” are what make architecture process  “complex”, the final architecture in itself should never be complex.

The greatness of the architecture is in its simplicity not in its complexity – isn’t architecture a simple representation of a complex solution?

When it comes to architecture, shouldn’t the architects Keep It Simple Sir/Ma’m (KISS)?

About The Author:

Girish Srikanteswaran Kothamangalam is a Senior Project Manager working for the Systems Integration unit in Infosys. He manages projects in the areas of Enterprise Portals and Enterprise Content Management Systems.

One of the key findings is that participants of the survey saw Enterprise Architecture as a capability that was core to their business and inherently part of their organization's crown jewels. However, given the daunting set of activities that most Enterprise Architecture functions have to execute today, the opportunity to work with ESPs and enlist them to execute some of these activities is real. In other words, some activities (the more tactical ones), can be outsourced to a strategic vendor partner.

We have engaged with multiple organizations to execute select EA activities in a collaborative model,  with the objective of ensuring that the EA function focuses on core activities such as business engagement, business alignment and strategic IT planning.

We are therefore seeing truly mature EA functions recognizing what is core vs context in their operating models and leveraging partners as necessary, to deliver even more business value cost effectively.

Next month’s Gartner Enterprise Architecture Summit in Las Vegas (Dec 10th-12th) will be one to watch. The real value of EA and its agility will be put to test in the next few quarters and years. How it ties back to this month’s Master Data Management Summit in Chicago (again by Gartner) will be even more interesting given that the set of analysts have very little overlap

Form an Architecture Governance Team
 

• A central team constituted with representation from stakeholders across the organization, should govern the planning, evolution and implementation of an Enterprise Architecture framework
   
• Architecture should be well thought through to meet the common goals of all stakeholders.
   
• The central team also should play a key role in establishing products, design and technology standards
  

Identify and implement common services for the enterprise

Factor in scalability

Reduce TCO

Consider shared vs. owned and virtual vs. physical

During the past few weeks I got involved in an interesting activity: analysis and review of responses to the 2008 Enterprise Architecture survey that Infosys has been conducting annually for the past few years.
 
This year, we invited technology leaders from our client base and the global IT community to participate. 207 respondents from a cross-section of industry verticals, geographies and organizational sizes completed a web questionnaire of 24 detailed questions.  A preliminary analysis of the results indicates a few trends, including:

• Enterprise Architecture is enabling business transformation [Does this surprise me?]
• EA practices continue to mature with increasing use of metrics and processes [Again no surprises on this front]
• Outsourcing of activities focused at Enterprise Architecture is an opportunity that most EA teams have not seriously considered [Now, this is interesting]

My colleagues and I brainstormed on the findings. One school of thought was that though the findings were surprising, we shouldn’t emphasize the discovery on Outsourcing since it may be perceived as trying to interpret data to fit our business model.  I can see an argument here:  we are a software service firm and our business model does centre on outsourcing and offshoring. On the other side, people like our practice lead in Europe, Sohel Aziz were equally vocal on why we should publish the finding. Sohel argued 'some of the data does indicate that organizations are not thinking of outsourcing elements of EA.  If we go back 5 years, we were not thinking of outsourcing testing…now it is one of the fastest growing IT segments globally.  Back then IT orgs thought they needed to do all this in-house too…. I see an opportunity to take the tactical elements of EA (such as solution architecture governance) and technology R&D out of the picture and getting that as a pay-as-you-go service.  So that the EA’s spend more time on the REALLY important stuff such a business engagement.” I couldn’t have summarized it better.

For those interested, here’s a plug: My colleagues from Europe plan to be at the Gartner Enterprise Architecture Summit next week. Copies of the summary of the survey [“Enterprise Architecture Expands its Role in Strategic Transformation”] will be available at the summit. The more detailed analysis of the finding will be published online soon

In my last post, I talked about the movie The 300 Spartans and the lessons it held for Architects about doing the right thing, courage under fire, looking for alternatives etc.

My Cousin Vinny (Year of Release: 1992; Director: Jonathan Lynn; Our Architect: Vincent Gambini, played by Joe Pesci; Architect's Character: Lawyer handling his first case for his cousin).

‘My Cousin Vinny’ is the story of a lawyer who finds himself defending his first cousin on the charges of first degree murder in his first ever trial. He has no experience as a lawyer and has never even attended the court as a lawyer, is totally unaware of the process or the protocol. He learns on the fly, makes silly mistakes on his first case, is excited by the trivial stuff, but makes a solid come back using his fundamental skills and saves his cousin from an almost certain seat on the electric chair.

A few important lessons that this movie can provide us are:
•    Never to let go of our fundamentals
•    Acknowledge and know what you do not know
•    Handling tough customers

Scenes to look out for:
1. There is a scene in the middle of the movie where Vinny thinks that he has built a connection with his prosecuting lawyer and as a result, got access to all his case files. When he tries to show off how smart he is to his fiancé, she points out that the prosecution is bound by law to share the case files with the defense lawyer, otherwise, it could lead to a mistrial.

First inference that we can draw from this scene is to know the law of the land before you get in to a project. Do your home work; find out what works and what doesn’t. Try to get any historical inputs about a customer if any precedence is available. If it doesn’t make you look smart in front of your customer, at least it will not make you look stupid. This is of particular help if your organization has had a tough history with a customer.

2. The second theme that flows throughout the movie is how Vinny manages the judge in whose court he is arguing the case. The first two times that he pleads the case, he gets himself arrested for the contempt of court. But he learns from his faults and by the end of the case, he makes a fan out of the tough magistrate.

Personally, I like working with tough customers. They bring about a point of inflection in your career which makes you improve just to be able to survive. At the end of a tough assignment, you come out with a new level of maturity and invaluable experience in the form of a few burnt fingers. Secondly, it’s usually the tough customers that can help take you and your organization places. Experiencing the way Vinny manages the magistrate, gives you good insights into how to manage tough customers – understand what excites them and what does not.

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

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.

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.