Architects Corner


  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Archives
    Archives Contains a list of blog posts that were created previously.
  • Login
    Login Login form
Posted by on in Enterprise Architecture
  • Font size: Larger Smaller
  • Hits: 5601

Get Leaner and Address Enterprise Problems in 30 Days Cycle - Redefining Enterprise Architecture, Part 1

Get Leaner and Address Enterprise Problems in 30 Days Cycle - Redefining Enterprise Architecture, Part 1

One of the popular myth that is doing the round i.e. “Enterprise Architecture is a discipline aimed at creating models.” Unfortunately, most of the Enterprise Architecture practitioners and several branded consulting organizations are caught in this trap. The situation has worsened as several architects & business process experts are building “composite models” and calling it “architecture” model. This ignorance has serious ramification, as several Enterprises are making considerable investments in this area without significant gain.

The situation has worsened as several professionals who are claiming to be Enterprise Architects have come from the IT background and their core skill continue to be in IT (software programming, database design & programming, middleware, cloud, etc.). But, their designation reads "Enterprise Architect".

In fact, some of them are so good at applying the buzzwords applicable in SDLC (software development cycle) or software development to address the complex enterprise issues, results are anyone's guess.

While department head or a CEO is asking "tell me how to address the cash flow problem of next month", our folks are busy discussing "agile" for delivering extra features in the software programs and how some API of module1 can be exposed to be used by module2 that is on cloud.

The problem in such case is that CEO or department head doesn't want to understand software components, APIs, network topology details (well justified). On the other hand, our architects are not interested in understanding the cash flow problem, sales cycle, key customers, billing cycle, manufacturing process, supply chain bottleneck and pressing business environment, etc.

There is no denying that the logic in the control box of a device or software component has the impact on the revenue of the organization. The problem is when you are not able to establish this visually and analytically. Also, how do you arrive at possible solution by explicitly defining the relationship, dependency and change impact, very critical.

IMHO, if you are an Enterprise Architect and your core skill continues to be IT ( i.e. SOA, Cloud, middleware, database, etc. essential & important skills, but they are NOT sufficient), Enterprise stakeholders as well as you will continue to get frustrated. The companies can not afford this anymore.

In fact last year, John Zachman (person credited with inventing the enterprise ontology) said “Enterprise architecture is a discipline that should help business managers to address their problems scientifically and quickly. End result is not to create the models, but to solve the enterprise problems”.


We feel good that iCMG Enterprise Architecture Consulting efforts have a positive impact on John Zachman’s revisit of definition two years back. At iCMG, we have proven beyond doubt that “Enterprise Architecture is a scientific basis for creating, maintaining and running an Enterprise. Use of enterprise primitives, complex composites, dynamic traceability models, the relationship matrix, gap analysis, impact analysis, simulations etc. provides necessary enterprise x-rays for visualization and understanding enterprise disorders. These enterprise x-rays provide the mathematical basis for enterprise diagnosis.
Last few years i.e. 2011-13 have been  breakthrough years as we have successfully demonstrated (few dozen times) how to address enterprise issues and problems in 30-45 days cycle. This is unlike popular belief that enterprise architecture initiatives need at least six months to deliver something significant.

The idea of Enterprise Architecture is to describe the fundamental structure of the Enterprise. In order to achieve this, we need to discover the underlying, elementary, single variable, “primitive” enterprise element. These primitives can be used for creating the necessary "solution" composite.

The way nature is populated with chemical compounds, enterprises are populated with “enterprise compounds” or “composites"(multivariable models).

One of the key challenge is to identify the enterprise elements (primitives) for any given Enterprise at any given point in time. We can help creating your enterprise primitives using ‘The Zachman Framework’. The Zachman Framework (6 x 6, two dimensional schema) with the “Communication Interrogatives” as Columns and the “Reification Transformation” as Rows. The Cells formed at the intersection between Interrogatives and the Transformations constitute the total set of primitives that are needed to describe the Enterprise in detail. The approach of creating the Enterprise Architecture using Zachman Framework has several benefits, such as :

  • Better understanding of the Enterprise anatomy using enterprise primitives
  • Insight about various Enterprise disorders and possible reasons behind them which are adversely effecting running and managing of the Enterprise.
  • Ability to create the Enterprise X-rays for effective diagnosis
  • Creating multiple solution model and test them.
  • Ability to predict changes due to implementation of the solution
  • Build a coherent and verifiable Enterprise Architecture.

In the case of human body, evolution of body structure is intrinsic. Whenever we take an x-ray, we always get an “updated” view of the anatomy. Unlike human body, the responsibility of keeping the enterprise anatomy live and updated is with the architecture team. It’s important to update the enterprise anatomy regularly to ensure that when you get the x-ray, they are not outdated. A diagnosis based on an outdated x-ray might result in a solution that is useless and expensive.

That’s the reason; it’s very important to keep the Enterprise structure alive and updated. To maintain, monitor and control the Enterprise Architecture, it’s important to have

  • Architecture Review Board (ARB)
  • Setting of Enterprise model Change Control Board (CCB)
  • Architecture Repository
  • Architecture version control
  • Metrics and measurements
  • Weekly, Monthly audit


One has to remember that “Enterprise Architecture” is not a time bound project or initiative. It’s the scientific way of creating, managing and running an enterprise effectively. Of course, specific enterprise problem could be taken up as a time-bound project. As and when new problems are being addressed, the enterprise primitives can be created, so as the basic composites. Just like a human body, every Enterprise will evolve (change) on a daily basis.

WhatsApp is a good example, Jan Koum uses its skill to address a business problem and gains big in the process. Why did facebook value WhatsApp, an enterprise with 32 engineers (reference news week) more than Southwest Airlines and Sony?

WhatsApp reached 450 million subscribers, in 4 years (while facebook had only 150 million in the same time from launch). It's only matter of time when they would have emerged as a big threat for Facebook. And when your survival stake, you can do anything ;-) including illogical valuation. So, it was Facebook "survival" strategy. Now this "survival" strategy has transformed to "growth" strategy to gain a big chunk of mobile messaging/voice market.

The point is that, if a motley group of 30 plus engineers could address a "business" problem and gain big time, why can't we do the same... address the business problem, short cycle remedy and  the rest will follow..such as funding, resources, time etc... including the budget for modeling and simulation tools ;-).

I plan to write a followup blog, detailing the 8 step iCMG methodology to address the enterprise disorders. Also, will share few case studies wherein it has been successfully implemented. Learning is an endless journey, and I hope to learn something from you as well ( your comments, experience, feedback). Thanks for stopping by for this post.

Last modified on
Rate this blog entry:


  • Guest
    Nagaraj Monday, 14 April 2014

    Good one...Looking forward to your next blog..

  • Jack Nelson
    Jack Nelson Monday, 31 March 2014

    A good read. You highlight much of the plight of many medium to large organisations with so called Enterprise Architecture practices.

    From my experience, many organisations 'do' EA via time-boxed agendas (funded, deliverable based, short-termed KPI focused) and do not manage knowledge and information gained nor enforce key principles via the architectural, IT and business representative review boards.

    Now these organisations may not value EA as they rightly should, and this could be why EA tend to function via multiple programs of time-based work. This is how EA has to deliver a value-add

    Organisations go through ebbs and flows when it comes to appreciating their EA practice. The challenges come in many forms, i.e. New Revenue/cost targets, disruptive new technologies, destructive existing technologies, market trends, customer wants and needs, government regulations, the changing of the guard (business and technology senior management), etc.. The challenge for the EA practice is to keep ahead of the ebbs and flows to ensure adaptation and congruence with the changing landscape.

    I would add Structure, Methodology and Business Alignment to what is important to have to maintain, monitor and control the EA

    I look forward to your follow up blog

Leave your comment

Guest Sunday, 30 April 2017