A Collection of Enterprise Architecture Definitions


Are you wondering what EA is? Or maybe you would like to understand what the industry standard definition is… Well your out of luck in this post. 🙂

All joking aside, it is sometimes helpful to see how others define this space. Obviously as an industry we need to standardize, however until then check out Robert McIlree blog. He has an ongoing collection of definitions around EA. Part 1 and Part 2 will give you some insights into what everyone else thinks.

Confused yet?

Tags: Enterprise Architecture


Asian Community Unites at IASA IT Conference 2008 to build the Architecture Discipline

The International Association of Software Architects (IASA) 2nd IT Conference 2008 was the largest IT Architecture event in South East Asia with more than 30 Expert Speakers, 4 parallel different tracks and 40 architecture sessions and 590 attendees from 9 different countries.

The goal of this conference is to instill technology neutrality in government policy and standards adoption. IASA has been a recognized as a key champion for enabling this.


Gianpaolo from my team, Vittorio, PIKOM/MDEC Executive dinner and Gorgeous Geeks in action during ITARC 2008

What was interesting about this was the unity from Asian government authorities (6 representatives ) representing their government all in the effort of establishing the IT Architecture Profession thru IT Architecture Professional body like IASA.

This is showing how us that worldwide the architect profession is starting to mature and standardize.

Tags: Enterprise Architecture

Why Good Architecture is Important Even in a Web 2.0 World

Mike Walker's Blog - Architecture at Twitter

Last week I read an article on Twitter’s Developer Blog called Twittering about Architecture. It was an interesting read because it validates many of my thoughts on the application architecture process and how it applies to the Web 2.0 and S+S world.

Looking at popular Web 2.0 sites such as Digg.com and Twitter.com we see that they are not immune to architectural challenges after a year of so in production.

Take a look at the snippet below:

Part of the impetus for this public discussion extends from the sense that Twitter isn’t addressing our architectural flaws. When users see downtime, slowness, and instability of the sort that we’ve exhibited this week, they assume that our engineering progress must be stagnant. With the Twitter team working on these issues on and off for over a year, surely downtime should be a thing of the past by now, right? Shouldn’t we be able to just "throw more machines at it"?

To both rhetorical questions, the answer is "not quite yet". We’ve made progress, and we’re more scalable than we were a year ago, but we’re not yet reliably horizontally scalable. Why? Because there are significant portions of our system that need to be rewritten to meet that goal.

I could look at this as an architecture zealot and say that they should of architected this right from the beginning but this is often a luxury that isn’t obtainable in many of the new software services as speed to market, initial cost and feature function often more important. The architectural qualities such as reliability, scalability and maintainability are often overlooked due to the immediate drivers.

So this begs the question, how do I address the immediate needs of my application or services while addressing the future concerns? This is a tricky question to answer but I think there is an general way to answer it.

Just like other process related with startups like obtaining venture capital, a business plan needs to be developed. The same should be true of your architecture. Before designing the micro level details of an architecture the architect should be thinking through what the future architecture drivers are and to what level they apply to the to be built architecture. Now with this thought through the architect can still build the more tactical components while preserving the long term vision of the architecture. How we do this is by building an architecture foundation that the components are developed on. This could be homegrown or purchased COTS platform. The point here is to have just enough process and architecture framework development without impacting (too much) the business of delivering software.

Digg.com is a great example of a service that went through the architecture rigor early. For more information on Digg’s scalability and performance ease check out the links below:

Because Twitter didn’t think though the architecture they selected an incorrect set of architecture components to support their architecture. See below:

Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency’s sake, Twitter was built with technologies and practices that are more appropriate to a content management system.

Taking a step back I have perceived that a common opinion is, "if I am developing a simple web 2.0 application then why should I think about architecture…". I don’t think this is the right mind set.  I suspect that the issue here is "over architecting". Developers and Architects often get scared off from architecture because they think it’s document centric and process heavy. It is true that there is a considerable amount of this.

Mike Walker's Blog - Just Enough Process

However, instead of looking at the architecting process as an all or nothing process we should be more pragmatic about approaching it. For example, this applies to all other IT processes such as project management, development and other processes such as security and risk management. As I stated earlier with "Just Enough of …" there is a dial that we can throttle back and forth that will determine what activities and to what level of detail they are performed. The same is true for architecture.

So Twitter is now in the midst of a gradual rewrite of their entire application. They are slowly replacing brick by brick their architectural foundation. As I stated above, this isn’t ideal and sometimes can not be helped. But I think with the right level of architectural thought in the early development processes this risk can be mitigated.

Our direction going forward is to replace our existing system, component-by-component, with parts that are designed from the ground up to meet the requirements that have emerged as Twitter has grown. First and foremost amongst those requirements is stability. We’re planning for a gradual transition; our existing system will be maintained while new parts are built, and old parts swapped out for new as they’re completed. The alternative – scrapping everything for "the big rewrite" – is untenable, particularly given our small (but growing!) engineering and operations team.

I also think it is very admirable that they Twitter is opening up to take requests for architectural alternatives.

To those taking the time to blog about our architecture, I encourage you to check out our jobs page. If you want to make Twitter better, there’s no more direct way than getting involved in our engineering efforts. We love kicking around ideas, but code speaks louder than words.

Tags: Enterprise Architecture

Burton Group Launches EA Guidance

image It looks like the Burton group is joining the fold with the other industry analysts in regards to Enterprise Architecture guidance. The new EA coverage area site went live on May 18 as part of the launch of IT1 from Burton Group. The initial content is in place, and is promised to grow in time

Mike Rollings will be leading this program from within Burton. I haven’t had a chance to review the two articles he has written but the titles look interesting.

The article titles are below:

After looking around the site a bit I did find that Burton is revamping it’s overall enterprise application strategy focus areas. As mentioned above the Enterprise Architecture guidance is published but this is all branded under the Burton Group IT1 site.

Included here are free resources such as: Podcasts, blogs, briefings, analyst reports (of course limited) and case studies.


Tags: Enterprise Architecture

Enterprise Library 4.0 Released


Enterprise Library is a collection of application blocks intended for use by developers who build complex, enterprise-level applications. Enterprise Library is used when building applications that are typically to be deployed widely and to interoperate with other applications and systems. In addition, they generally have strict security, reliability, and performance requirements.

The goals of Enterprise Library are the following:

  • Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
  • Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding their own code.
  • Ease of use. Enterprise Library offers numerous usability improvements, including a graphical configuration tool, a simpler installation procedure, and clearer and more complete documentation and samples.
  • Integration. Enterprise Library application blocks are designed to work well together or individually.

These are typically rationalized through:

There will be a webcast in June 2008  giving an overview of the new features of Enterprise Library 4.0. You can find more detail on the Enterprise Library landing page.

What’s New

This release of Enterprise Library includes the following:

  • Integration with the Unity Application Block
  • Windows Management Instrumentation (WMI) 2.0 support and improved instrumentation
  • Performance improvements (particularly, in the Logging Application Block)
  • Pluggable Cache Managers
  • Visual Studio 2008 support
  • Bug fixes

Note: existing public APIs (v3.1) are still supported.


Contrasting Solution Architecture with other Architecture Roles

I ran across this great post that takes a stab at contrasting the various architecture roles. I think Karthik Vijayakumar does a good job with the overview. See below: 

architecture role relationships

EA – Enterprise Architecture
EBA – Enterprise Business Architecture
EITA – Enterprise IT (EIT) Architecture
EITIA – EIT Information Architecture
EITAA – EIT Application Architecture
EITTA – EIT Technology Architecture
EITSIA – EIT Software Infrastructure Architecture
EITHIA – EIT Hardware Infrastructure Architecture
SA – Solution Architecture

This is topic is an area in which people in general struggle with. I am glad he put some effort in defining. I have used similar ways to articulate these roles as well. This view  gives us the relationship between these roles. I think this is important to see. I have used spider diagrams as overlays on the other roles to show how the competencies overlap.

Also, I show these how these roles are not hierarchal by viewing them in terms of breadth and depth. This type of illustration shows us the scope and context of the various architecture roles.

Thoughts / Comments?

Tags: Enterprise Architecture