EA - Enterprise Architecture in Action

- Mohan Babu K 

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.

If we were to take a “day in the life of an Enterprise Architect” perspective, typical activities could be broken into innovate-vs-sustain, with a question: How much effort to be expended in sustaining versus innovating tasks?

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

Posted by Guest Author at 2:16 PM | Permalink | Comments (0) | TrackBacks (0)

- Mohan Babu K

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!

During the past few years, I have worked with clients that have adopted Enterprise Architecture tools to varying degrees of success. Very few, at a considerable cost and effort, claim to achieve the utopian goal of mapping an enterprise architecture continuum in an ongoing basis (the stuff tool vendor case studies and marchitecture are made of). Why the high rate of dissatisfaction? Ask Enterprise Architects for a wish list in an EA tool and it could go somewhat like this:

• 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

Posted by Guest Author at 2:46 PM | Permalink | Comments (2) | TrackBacks (0)