Yesterday I had jury duty; one of only two civic duties enumerated in the US Constitution – the other being voting (ok paying taxes might count as three, but let’s not go there).  Anyway, several hours of sitting in a court house did get me thinking about the “rules of evidence” for architecture.

A common pitfall that IT organizations fall into when trying to formalize the practice of architecture is to setup an architecture review broad (ARB) without proper foundation; specifically without setting down the rules of evidence for architecture.  In ancient times the village elders or some monarch dispensed justice without formal legal structure, but I’ve yet to see an ARB that wielded this kind of absolute authority over IT projects.

So just as modern courts are governed by rules of evidence, the ARB must define what is to be presented as part of an architecture review and what criteria is to be used to judge the fitness of what’s presented.  TOGAF™ provides a succinct description of the function of an “Architecture Board” without trying to define any strict formula for an ARB to follow.  Nor will I try.  Instead I’ll just focus on some of the basics.

A common ARB function is to ensure conformance to standards.  If the organization has not defined any standards or has failed to define standards that are relevant to the projects that the ARB will review, then this part of the review becomes little more than a debate between architects.  It may be a debate in good faith, but that’s called a design review and whereas I’m all in favor of architects reviewing each other work and giving feedback, this process generally lacks the kind of demonstrable benefits that are required to justify anything beyond the most cursory investment of resources in the ARB.

I mentioned the importance of standards being relevant.  Standards are defined because they either solve a common problem, thus saving time and resources from having to solve the same problem over and over again, or they support some other architectural objective such as security or ease of integration.  If one can’t demonstrate how either of these is the case for a project under review, then the standard is not relevant and enforcing conformance becomes a challenge.

When deciding where to start with defining standards it’s a good idea to look in three areas:

1. Look at what is in common use in the organization today.  This represents a set of successfully applied solutions to a set of known problems.  It also represents technology that is already familiar to the organization and skills sets that are already available.
2. Look at the pipeline of projects in development or under consideration.  This represents a set of problems that will need to be solved in the near future, but be sure to look for common problems, not simply interesting ones or even the hard ones.
3. Look at known architecture priorities of the organization.  E.g. improving security, enhanced analytics capabilities, or improved integration between systems.

Architecture Artifacts

A well defined set of standards is not the only requirement for a successful ARB.  Defining what has to be brought into the review is also important.  Besides allowing the project team to appropriately prepare for an architecture review it also ensures that the ARB get’s a complete and accurate picture of the project under review and solutions being proposed.

For many a project teams, an architecture review is nothing more than a hurdle to be passed with as little delay or disruption to the project plan as possible.  Thus the project team is often incentivized to game the review process, not to embrace it.  Gaming the review process is usually just a matter of presenting those aspects of the project that are most well understood and avoiding those areas that are less understood when presenting the project to the ARB.  This is only possible when the material to be presented is left up to the discretion of the project team.

Defining what architecture artifacts should be brought into a review should be based on the artifacts that are already being created as a part of the project.  The challenge here is that many an organization lacks a really well defined architecture methodology that all projects follow.  Exactly what type of artifacts should be a part of a project architecture methodology, I’ll leave for another (much longer) posting.  The key is that when defining the artifacts that should be created as part of the project and brought into the architecture review one should keep in mind what information about what aspect of the project or the proposed solution each artifacts is communicating and how each artifacts is used in future steps in the process.

Scope

The scope of the architecture review also needs to be defined.  Is it just about application architect? Does it cover data and information architecture?  Does it cover infrastructure?  For whatever scope is defined for the ARB, the appropriate standards and artifacts need to be defined.  Also the ARB needs to include subject matter experts across the full scope of the ARB.

Many organizations divide the architecture review process across multiple boards.  This separation of concerns can be useful in ensuring that each area of concern is fully addressed, but it can also provide an additional burden for the project team to have to prepare multiple reviews.  When choosing to separate concerns it is still important to have some coordinating function to ensure that all the appropriate concerns are addressed; this is often delegated to whatever general project governance process exists.

Outcomes

Justice Potter Stewart said that he couldn’t define pornography, but “I know it when I see it”.  I often feel the same about the term “enterprise transformation”.  Not that there haven’t been many attempts at defining transformation; I just feel that most fall short of addressing the vernacular use of the word.  Particular they don’t address just what is it about transformational projects that make them harder than any other large project.  Nor do they help identify when “transformation” is required.

So let me posit a different term: inertia.  Often when we use the term “transformation” what we are really talking about is significant or sudden change in inertia.  Consequently the role of Enterprise Architecture can be defined in terms of how it is used to manage inertia in an enterprise.

Enterprises develop inertia over time.  And just as inertia keeps a gyroscope from changing direction, inertia stops enterprises from changing themselves.  Transformation is about overcoming inertia to change direction.

Inertia is not always a bad thing.  Inertia can be very valuable in keeping an enterprise on track. When we talk about institutionalizing change we are talking about creating inertia that will keep the enterprise from reverting back to its old ways.  In this case inertia is the gyroscope that keeps the organization moving in the right direction.  It guides future decisions as processes and systems are updated.

Thus not all change is a change in direction.  Some change may be a course correction or a detour around a temporary obstacle.  Some change may be simply to keep going the same way but more efficiently or faster.  These changes may nor require a change in inertia at all, or may require only minor changes in inertia.

However, when a change in direction is significant or sudden inertia will become a major obstacle to change.  This requires an effort of Herculean proportions; this requires transformation.

Types of Bad Inertia

• Organizational Inertia – This is about people resisting change.
• Managers and executives resist change when they fear they will lose power because of it.
• Employees resist change when they fear they will lose their job because of it.
• But mostly people fear change because they lack confidence in the portability of their existing skill set and their own ability to adapt or learn new skills
• Financial Inertia – This is about the cost of change. Pre-existing investments in capital and resources make change expensive:
• We just built that factory last year.
• We just implementation that system.
• We’re still depreciating that expense.
• Process Inertia - The “we always do it that way” syndrome.
• System Inertia - We do it that way because that the only way the system supports and the system is too hard to change.

Strategy Sets the Course, Execution is the Journey

When we talk about direction for an enterprise we are talking about strategy.  Strategy does not simply specify a straight line direction; strategy defines a course from where we currently are to where we want to go.

Execution is how we translate strategy into action.  When strategy and execution are aligned the enterprise moves smoothly along the course laid out in the strategy.  Over time strategy changes and execution must change with it, but if inertia has built up and is not properly accounted for strategy and execution can drift out of alignment.  The problem is not that we don’t know we need to change direction; the problem is we can’t change direction as easily as expected.

Take the example of a car driving on an icy road.  If the road suddenly curves the driver will see it and know that he/she must change direction to match the curve.  So he/she turns the wheel of the car, but the ice on the road has robbed the tires of the traction required to execute that turn; the car continues to go straight.  The driver continues to turn the wheel for the expectation is that turning the wheel will cause the car to turn.  Finally the tires may summon enough traction to execute a turn, but at this point the driver may have over turned the wheel and the car turns more than required.  Anyone who has lived and driven in a cold winter climate knows how this story ends.

Unfortunately unlike the driver of the car on the icy road, it is not as easy to recognize when the enterprise has failed to change direction as desired.  Often times the enterprise fails to respond to even what are considered minor changes in strategy. This failure to respond may go unnoticed as may the next change in strategy and the next.  Left unattended the misalignment between strategy and execution grows over time.  Worse yet as execution deviates from strategy making strategy changes become harder because the assumed starting point may not be correct.

Back to the analogy of the car on the icy road; since the normal feedback associated with turning the wheel is not available, the driver turns the wheel randomly until he/she is no longer certain in which direction the wheels are pointing.  This is an enterprise skidding out of control.

The Role of EA in Avoiding the Car Wreck

It’s popular to talk about Enterprise Architecture as aligning business and IT.  Like “transformation” that has always struck me as too vague.  I prefer to talk about EA as aligning execution to strategy.

So if we define transformation either in terms of change to strategy or re-alignment of execution to strategy, the role of EA in transformation becomes one or more of the following:

1. Avoiding misalignment of strategy and architecture in the first place.
2. Recognizing when there is misalignment between strategy and architecture.
3. Identifying specific misalignment between execution and strategy.
4. Root cause analysis in the misalignment of execution and strategy.
5. Designing new modes of execution that align with strategy.
6. Identifying and minimizing the potential for creating bad inertia in the execution of strategy, in particular avoiding System Inertia, one of the most common and troublesome forms of inertia.

In the following, I try to evaluate the semantic dimensions of “architecture” compounds – as a framework for structuring discussions, and facilitating communication. Subsequent postings will evaluate divergent interpretations of terms commonly used in the context of enterprise architecture, and provide recommendations how to handle these interpretations in interactions between architects.

Please contribute your own views on how the word architecture is used. It will be extremely interesting to gather additional aspects of the term.

Kind Regards

Thomas Obitz - Principal Architect

Composing “Architecture”

Within the IT community, the term “architecture” traditionally is used in one of three ways: One is as a characterization of an object (the “architecture” of a cathedral), the second is to describe the process of designing these architectures[2].  The third meaning – the profession of the architect – today is derived from the second[3].

In the characterizing context, an XYZ architecture can be (without claiming completeness)
·         the architecture of an XYZ (Enterprise Architecture - Architecture of an Enterprise)
·         an architecture for an XYZ (Enterprise Architecture - Architecture for an Enterprise)
·         an architecture describing the XYZ aspects of something (Information Architecture - Architecture describing the information assets of an Enterprise)
·         an architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (Information System Architecture)
·         an architecture consisting of XYZs (Process Architecture - Architectural description consisting of process models)
·         an architecture in the state XYZ (Target Architecture)
As an art, we find “XYZ architecture” as
·         architecture using an XYZ approach (Enterprise Architecture – doing architecture using Enterprise Architectual approaches, even for a smaller unit than an enterprise, or for a government)

Architecture of an XYZ (constitutional)

 ISO 1471 talks about the “architecture of software intensive systems”, which was usually abreviated into “software architecture”. This straightforward interpretation has been transferred to the field of Enterprise Architecture only recently. The “Architecture of an Enterprise” therefore may describe the relevant aspects of an enterprise, the way an organization is structured, how its departments interact, and how they generate value.

Architecture for an XYZ (demarcational)

 The terms “Enterprise Architecture”, “Departmental Architecture” or “Line of Business Architecture” can be used to describe the scope an architecture is relevant to. An “industry architecture” is an architecture not of, but relevant to a specific industry. If used in this way, “Enterprise Architecture” does not explain what aspects it describes, but just that it applies to the enterprise as a whole. This missing description, however, can be inserted between the two terms: An Enterprise IT architecture describes the IT landscape for the enterprise, an Enterprise Data Architecture its data assets.

Architecture describing the XYZ aspects of something (projective)

 “Enterprise Business Architecture” can be used to describe the business aspects of an organization, i.e. the aspects related to achiving its vision and purpose. Enterprise Information Architecture describes the information related aspects of an organization, including their relationship to other architectures.
This use of XYZ architecture focuses on the aspects of architecture related to a specific concern. It therefore comprises the projection of architecture to a viewpoint or set of viewpoints, and hence is highly dependent on stakeholder concerns.

Architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (contextualized)

 When John Zachman wrote his famous paper “A framework for Information Systems Architecture”[4], he spoke about much more than just information systems. His framework considers the context in which an organization builds such systems, and which influence their gestalt.
It is common to perform such contextualization in many compositions of the term architecture, and this approach can be considered as an extension of the constitutional use of the compound.

Architecture consisting of XYZs (compositional)

 When talking about “Process Architecture”, we are by and large talking about a documentation set composed of process documents. A similar thinking is behind the (outdated) perception of data architecture as a corporate data model.

Architecture in the state XYZ (state)

 Using the terms “as is” or “target” architecture describes a state in the development of architecture.

Architecture using an XYZ approach (method)

Architecture organized in an XYZ fashion (organizational setup)

Federated architecture is a way of performing architecture activities in a specific organizational setup. It can be used both for architectural deliverables (where deliverables of a higher level are detailed at the next level) as well as for a way of doing architecture (with a defined distribution of responsibilities between layers).

“Identify 10-12 [application] ‘architectures’ that are standard.  The challenge is to build a decision tree to drive the ideal architecture.

Q1: Are there any defined set of enterprise architectures?
Q2: Are there any decision analysis mechanism (like that for determining architecturally significant requirements in ATAM) already available?”

I’ve seen a few companies attempt to do similar although not quite this ambitiously.  Most organizations have started by identifying common architects that are already in use within the organization and generalizing them.  This has the decided benefit that the architects represent technology components already known to the organization and have proven implementations against use cases relevant to the organization.  I fear any effort to define a standard set of architectures outside the context of a well define problem domain (i.e. the environment of a given enterprise) would be too abstract to be practically applied within any given IT organization.

• The TOGAF Technical Reference Model defines a core taxonomy for describing the components and conceptual structure of an architecture.  http://www.opengroup.org/architecture/togaf9-doc/arch/chap43.html
• FEA (Federal Enterprise Architecture) defines a set of Reference Models for describing the important elements of architecture in consistent ways. http://www.whitehouse.gov/omb/e-gov/fea/
• There are several good catalogs of common enterprise architecture patterns:

• Fowler: Patterns of Enterprise Application Architecture” http://martinfowler.com/eaaCatalog/

• Hohpe & Woolf: “Enterprise Integration Patterns” http://www.eaipatterns.com/

The last part of the problem is even more challenging:  Given a problem how does one pick the appropriate architecture? 

Methods like ATAM are designed to evaluate a given architecture against a given set of requirements.  So using ATAM would require evaluating each standard architecture against the given requirement set and picking the one that fits the best; this would be impractical in the real world for more than two or three architecture.  I’m not sure that inverting the function is possible in a generalized way.  However, if as said before, one narrows the problem domain to a single enterprise and a sufficiently small set of architectures one may be able to define such a function.

The other challenge for picking an architecture based on any given problem is ensuring that the problem has been broken down appropriately first.  Most large enterprises have complex problems, but the successful solution is not an equally complex solution but rather a collection of simple solutions.  Each one of these solution components may map to a different standard architecture.  This componentizing of the solution also simplifies the process of matching problems to architectures since it means both simpler problems and simpler architectures.  Complexity is the enemy.

Another technique for managing the complexity is to divide the standard architectures into layers.  If one limit the problem domain to defining standard physical architects (disk, memory, CPU, networks, I/O, etc.) then this starts to sound a lot more doable.  This may not be the ultimate goal, but it's the start the first step in a layered approach that starts with defining standard physical architects, then standard application architectures, data architects, process architectures, security architecture, etc.  Thus the process of mapping a problem to a standard architecture would actually involve picking an appropriate architecture from each layer.  One may find that each layer has a relatively small set of standard architectures, but in combination the layered architectures represent dozens of complete architectures.  The FEA Reference Models sort of takes this approach.

So whereas the goal of defining standard architectures within an organization has many advantages not the least of which are: reduced technology complexity within the organization, increase reuse of both components and skill sets throughout the organization, decrease risk, and decrease cost.  Unless you happen to be the Federal government of the United States of America don’t look for general solution, focus on the problems in your organization and the tools already at your disposal to develop more specialized solutions that give more immediate benefit.  Where there is some effort, there is some success.

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.