Mike Walker's Blog

Presenting at TechEd 2009

Hello all! I will be presenting at this years TechEd on The Role of the Architect in Turbulent Times.  If your around swing by or if you would like to get together at the event to chat let me know.

Here are the details of the session:

Title

Role of the Architect in Turbulent Times

Abstract

With faltering economies and the resulting shifting of priorities, architects must be ready for change in their role. Innovative new technologies such as Cloud Based Computing, Software as a Service and Virtualization open up new and exciting opportunities for architects to show value in their organizations. In this session we discuss how the role of the architect has changed, introduce new architectural patterns and show how to "do more with less".

 

Technorati Tags: TechEd,Microsoft,Economy,Architecture

Microsoft Enterprise Architecture Framework?

Your puzzled by the title aren't you? In a recent e-mail discussion the question came up regarding enterprise architecture frameworks. The questions was “Does Microsoft have an EA framework similar to TOGAF or Zachman”?  I decided to post this here on my blog because it might be useful information to you if you ever wondered the same.

There was a lot of people that had very interesting things to say about the topic but few answered the question. Some of the dialog included:

• The frameworks we do have and how they align
• Personal opinions on frameworks in general
• Services roadmaps
• Why we should/should not have an EA framework
• etc.

Today, Microsoft does not have an EA framework, methodology or a EA product as such. What Microsoft does have is some key pieces to the EA puzzle. One example of how this is directly demonstrated in the Enterprise Architecture Toolkit (EATK). The EATK shows customers how Microsoft can help make their EA efforts actionable through Microsoft technologies. The EATK which is a solution accelerator not a product, does have unique methodology and process components that could be contributed to an open standards bodies such as IASA, Open Group, EACOE or Zachman as examples. But is it a framework? No it is not. It is one tool in the EA Toolbox.

To further this notion, below is a snapshot of a mapping matrix on how the EATK aligns with TOGAF’s Architecture Development Method (ADM):

ADM Phase	ADM Steps	Scope	Alignment with EATK
A. Architecture Vision	1. Project Establishment	Limited	Integration with Project Portfolio Server
	2. Identify Business Goals and Drivers	In	Principles, Policies and business drivers that are captured at the corp. level and at the solution levels
	3. Review Architecture	In	Captured in the System Architecture Document Discoverable through the Architecture Metadata Repository (AMR) Collaboration mechanisms for sharing and validation of architectures
	4. Review Architecture Principles and Business Principles	In	EATK allows users to review Principles, Policies and Standards on the EA Portal.
	5. Define Scope - Breadth of architecture coverage - Level of detail to be defined - Domains that should be covered - Schedule concerns - Assets to be leveraged	In	Currently covered in the System Architecture Document AMR Pattern References allow for access to patterns
	6. Define constraints - Time, Schedule or Resources	Limited	Covered by Office Portfolio Server for PPM Practice
	7. Identify Stakeholders and concerns, Business Requirements, and Architecture Vision	Limited	Covered by Office Portfolio Server for PPM Practice
	8. Document the Architecture Statement of Work	In	Currently covered in the System Architecture Document. However this is a manual activity with little automation
	9. Get Approval for Architecture Statement of Work	In	Currently covered in the System Architecture Document. However this is a manual activity with little automation. Windows Workflow foundation is setup to do this task.
B. Business Architecture	1. Develop baseline architecture description	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
	2. Identify reference models, viewpoints, and tools	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
	3. Create Business Architecture Models	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
	4. Select Business Architecture Models	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
	5. Conduct a formal checkpoint review of models with stakeholders	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
	6. Review non-functional criteria	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
	7. Complete the business architecture	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
	8. Perform gap analysis and create report	In	Supports the document management and workflow aspects however there is limited automation to these tasks.
C. Information Systems Architecture	1. Develop baseline architecture description(s) - Conceptual Data Model - Logical Data Model (views of information relevant to arch) - Data Management Models (life cycle, management view, etc)	In	This is accomplished in many ways: 1. System Architecture Document - This document template provides the mechanism in which to document your baseline descriptions. The document conforms to TOGAF from a method and artifact perspective and IEEE 1471 from an information model. The document uses a 1471 supported custom XML schema to represent information inside the document. 2. Architecture Meta-Data Repository (AMR) - This facility provides the architect with the right information to support the creation of a baseline description. 3. EATK Collaboration Mechanisms - Architectures have multiple viewpoints which means that there will most likely be more than one architect working on a particular architecture. There are built in collaboration features to aid in developing the architecture baseline.
	2. Review and validate principles, select reference models, viewpoints, and tools	In	1. AMR Pattern References - The core to this task is being able to surface this information to the architect. The AMR provides this facility by integrating both into Microsoft Word System Architecture Document and through SharePoint Portal for architects. 2. EATK Custom Workflows - Validation can occur through the sample architecture review and Architecture Review Board (ARB) processes.
	3. Create Architecture Models	In	There are a variety of activities have to occur to create architecture models. 1. System Architecture Document - First you need a place to describe those modes. The EATK uses the System Architecture document for this task. 2. Visio - Most architects and developers use Visio to model their architectures. The EATK has linked valuable information from the AMR so that the shapes in the model link to real assets and patterns. 3. AMR Pattern References - The AMR provides the facility for storing assets and building blocks that an organization has standardized upon.
	4. Select Architecture Models	In	Selection of a model usually entails the architect has a way to view the current approved building blocks and then must go through an approval process to validate the selection. The EATK does this through two key components: 1. System Architecture Document Patterns Browser Task Pane / EA Portal 2. Architecture Review Board Process
	5. Identify Candidate Applications	In	AMR Pattern References
	6. Conduct a formal checkpoint review of the Architecture Model and Building Blocks with stakeholders	In	Architecture Review Board Process AMR Pattern References EATK Collaboration Mechanisms EATK Custom Workflows (Sample WF provided)
	7. Review Non-Functional Criteria	In	Document Templates in document libraries
	8. Complete Architecture	In	Integration of System Architecture Document into workflow
	9. Conduct Checkpoint/Impact Analysis	In	Architecture Review Board Process AMR Pattern References EATK Collaboration Mechanisms EATK Custom Workflows (Sample WF provided)
	10. Perform Gap Analysis and Create Report	In	Template in a document library
D. Technology Architecture	1. Develop Baseline Technology Architecture Description	In	There are a variety of activities have to occur to create Architecture Descriptions. 1. System Architecture Document - First you need a place to describe those modes. The EATK uses the System Architecture document for this task. 2. Visio - Most architects and developers use Visio to model their architectures. The EATK has linked valuable information from the AMR so that the shapes in the model link to real assets and patterns. 3. Metadata Repository Integration - XML Web services layer to allow third party tools to submit architecture descriptions to repository. 4. Architecture Decision Template - A tool used to iteratively build a series of decision against an architecture.
	2. Create Target Technology Architecture	In	Same as above in baseline technology architecture
	3. Create a Baseline Technology Architecture Reference Models, Viewpoints and Tools	In	Same as above in baseline technology architecture
	4. Consider an Architecture Model of Building Blocks	In	Same as above in baseline technology architecture
	5. Select the Services Portfolio per Building Block	In	Same as above in baseline technology architecture
	6. Confirm that the Business Goals and Objectives are Met	In	Mapping to business architecture is supported but will need to be custom developed through the UI of choice.
	7. Choose the Criteria for Specification Selection	In	Same as above in baseline technology architecture
	8. Complete the Architecture Definition	In	Same as above in baseline technology architecture
	9. Conduct Gap Analysis	In	Gap analysis supported with repository placeholders to correlate that information with an architecture

As shown above, Microsoft can be an enabler of these EA practices. There are similar mappings with other industry adopted EA frameworks. In general Microsoft has always been an enabler with their products. Microsoft has a real opportunity to bring these solutions together by orchestrating the platform in a meaningful way.

So my take on this is that Microsoft really shouldn’t be in the business of creating EA frameworks. There isn’t a whole lot of value for Microsoft to do that. If you look around at the industry, you will see that most of the players that did create EA frameworks are now consolidating them into standards bodies. Those include:

• IBM
• Cap Gemini
• SAP
• EA Tool Vendors
• Governments like the Netherlands
• etc.

We should leave this up to the industry to define, they have the expertise here. I think there are particular aspects to an EA framework Microsoft can contribute and innovate to, but owning and building from scratch is something I feel isn’t a good idea.

Martin Sykes, a senior architect in the UK had summed it up perfectly:

Customers rarely ask us to provide them with a complete EA framework and methodology but they do want to know how we can help them improve what they have – and this has meant we need to be able to judge the situation, identify the weaknesses and then apply the right combination of perspectives from business, solution, technology, governance, portfolio mgmt etc.

However, there are many other examples on how Microsoft is helping provide thought leadership, guidance and tools in the Enterprise Architecture space. Below are direct and indirect examples:

1. Guidance on the Microsoft Enterprise Architecture Portal
2. Guidance and Thought Leadership on Blogs from Microsoft Employees:
1. Nick Malik
2. Gabriel Morgan
3. Mike Walker (Me) – [EA Specific]
4. Full list of Microsoft architect blogs here and architecture community blogs
3. Development and Operations frameworks such as Microsoft Operations Framework (MOF), which also include the Microsoft Solutions Framework (MSF)
4. Methodologies and tools to tackle capability modeling and analysis through Microsoft Business Architecture (MSBA)
5. Tools and Platform Products that aid with Service Management, ALM, Operations and PPM. Some of these  that include (not going to list them all):
1. Project Portfolio Server – APM and PPM
2. SharePoint – Centralized Process/Workflow, Collaboration, ECM, Portal, etc.
3. Visual Studio Team System – Development asset repository, development process support, class modeling through new UML support, etc.
4. Systems Center – Operational / Service management
5. Dynamics – Incident management, Green IT dashboards, etc.
6. Oslo – Model driven development support and deployment

 

So in summary, where I think Microsoft can add value is by enabling these industry frameworks through our unique products, platforms, thought leadership, frameworks and guidance by orchestrating them in a meaningful way. The EATK does this by rationalizing the platform assets with EA specific business knowhow on top of a extensible platform we can address key EA scenarios. By extending this toolkit and other like it (MSBA, MOF, MSF, etc. ) I think we can make these EA frameworks much more actionable.

What do you think?

Technorati Tags: Enterprise Architecture,Frameworks,Microsoft,MSF,MOF,EATK

The Impact of Recession on Green IT

The recession seems to have a grip on everything we do. Before going into a major downturn Green IT was an emerging activity. There is no doubt that the environmental predictions have been forces that drive this activity, however the forcing function for most companies has been regulation, especially in Europe. For IT architects, these are interesting times, with so many new technologies and concepts such as Cloud, Green, Virtualization, etc. the choices seem endless.

After reading a few publications in my spare time, I started to wonder how much the recession really has effected Green IT. I have waited to comment on this because there seems to be conflicting reports. On one hand there is talk about how Green IT will be the next big IT wave while other reports state that it will have a minimal impact.

What tipped the scales for me was the Gartner article entitled “The Impact of Recession on Green IT”  released late last month and it was very interesting to see the analysis. This article was a survey of Gartner customers that wanted to get to the heart of the matter to figure out where Green falls into their project planning. Surprisingly, customers are not planning as much Green activities as once thought. There were some great data points in the article. If you have a subscription it definitely worth it to take a look.

While I can see limiting project spend I can’t see why not to do these activities even if it was for saving money in operations. As far as Green goes, I would of thought with the recession would encourage organizations to optimize and consolidate. At a minimum there are some Green-ish types of projects that will help organizations lower power consumption, cooling control, operational support costs, licensing, complexity, etc.

I think there is a great deal of value in kicking off these Green IT  projects. I was involved in operations optimization activities a few years ago. There is a lot of money to be saved if your data centers have not been optimized.

Below are some practical projects to control costs and becoming more green:

• Consolidation Strategy – Building a strategy to consolidate both applications and hardware to control the amount of unnecessary redundancies.
• Meter Systems – Understanding the over utilization (CPU), consumption or power and carbon footprint of a system can help derive patterns in how the solutions work. By doing so it may lead to consolidation, scheduling of services for a shared services environment or an application optimization project.
• Technology Life Cycles – I talk about this a bit from an EA perspective. Technology life cycles will provide you with a way to consistently review solutions to classify them. There are many classifications that can be used but for the sake of the topic maybe we would want to put levels of Green compliance on solutions. Technology Life Cycles not only classify these solutions but also provides a way to govern or retire solutions that do not make sense any longer.
• Over Engineering the Data Center – Sometimes us architects have a tendency to over engineer things a bit. Obviously this isn’t very costly or green. A common over engineering mistake is temperature control. Making the data center cooler than it needs to be is a big power hog. There are little things like this example that can help.

Every little bit helps. It comes back to understanding your environment, that is where understanding your consolidation strategy and metering comes in.

See my other posts on Green for more information.

Technorati Tags: Green IT,Sustainability

My Blog has Moved

I just moved my blog to www.MikeTheArchitect.com . The RSS should still be the same so if you have linked to my blog through the blogs.msdn.com/MikeWalker address you will need to update your links.

Finally Made it to the Top

A teammate and I were chatting about search ranking and I was telling him about how I am battling it out (maybe battling out is a bit of an exaggeration) with other Mike Walker’s in the world especially the one from the National Enquirer. 

I am happy to announce I have done it! After many years of being second to Mike Walker from the National Enquirer I have finally moved up to the #1 position, but for how long. I won’t last past the next movie star scandal.

Thanks everyone that have linked to me and subscribed to my blog!

http://www.google.com/search?hl=en&q=mike+walker 

Results 1 - 10 of about 17,700,000

Technorati Tags: Mike Walker

Microsoft Green Computing Commitment

There has been some really great announcements coming from Microsoft in terms of Green IT and Sustainability here in recent months. One big one is the Environmental Sustainability Dashboard.

Watch Environmental Sustainability Dashboard Demo

Top down support is coming from Steve Ballmer as today he sent out a corporate responsibility letter to the company outlining all that we are doing in this space. He says,

"Addressing global warming is a responsibility we take very seriously at Microsoft." – Steve Ballmer

You can find the details of this on a new site on Microsoft.com called Innovating to Improve the Planet. there you will find what Microsoft is doing to be Green and help customers be Green.

There are additional activities that are happening at Microsoft to help with this problem. For one, my team. In my team, Lewis Curtis is focusing on Green IT and Virtualization. He has provided insights into this problem a bit:

• Providing insights on his blog, Thoughts from the raised floor
• His contributions to the Architecture Journal 18 focused on Green Computing, Environmentally Sustainable Infrastructure Design
• Predictions on Green IT Trends
• Two upcoming TechEd Presentations entitled:
  • Understanding environmental compliance, policy and regulation
  • The reality and impact of virtualization

The Software Enabled Earth blog is another great Green IT / Sustainability resource for news and activities from Microsoft.

Technorati Tags: Green IT

Mapping Current State Architectures across the Enterprise

All the time I get the questions about how to do current state architecture or “as-is” architecture at executive briefings (EBC), at events or through our customers. Recently I was asked about this in regards to an effort a large enterprise that is undergoing an effort to map out what their current architecture. As with many companies large and small, there is a reconciliation of IT assets that are being being collected and hopefully distilled into something meaningful to make decisions off of. This is compounded by the economy that has a tone of “doing more with less” and IT optimization.

With the question of current state architecture, it is both a deep and vast area to cover. As you can see from my choice of the image above (depiction of Christopher Columbus claiming the New World) this is a substantial space to cover.

The reason I say this is that it isn’t as simple as understanding a modeling language or notation and then run out and document your enterprise. Outside of the tooling, architecture standards and technology you must understand some outside forces when performing a current state analysis. Below are a sample (not in order) of aspect you must understand:

1. Deep understanding of the CEO & CIO mission and objectives
2. Deep understanding of mission critical solution areas
3. Deep understanding of the enterprise
4. Deep and vast understanding of the business
5. Vast understanding of your IT landscape
6. Vast understanding of your industry

You maybe wondering, I am an architect why should I care about these? Simply put, you must care because you will have to figure out where to start from. Do you start at the CRM system? How about the mission critical Online Banking System? Or maybe start simple with the FoxPro database applications in a LOB somewhere.

If you are not careful you can get a derive to a current state that is neither understandable or usable as seen from the popular example below:

Having context and purpose before walking into an very nebulous architecture effort such as this very important to your overall success. Metrics being the driver of success here. If you are able to qualify the effort you can get some measures of success out of your effort.

So to be effective at you current state analysis we must tie into the organization priorities through a repeatable framework. This corresponds with a repeatable current state process or methodology that is derived from the mission and strategies of the company all up. A model like shown below.

I often hear of horror stories of companies doing a massive current state analysis that turns into a multi-year project and yielding minimal results. The key here is to be strategic about your current state architecture efforts. The issue is that it is easy to “rat hole” into the classic problem of analysis paralysis.

This is an iterative process of focusing on assets that are the highest to lowest priority. Since the future state of any company and subsequently the IT environment is always in motion, we must be mindful of that this movement will occur and build that movement into our plans. The most effective way to deal with this is to create an iterative process like the one below to effectively perform a current state analysis.

 

As you can see we are bridging the CEO/IT strategies into account and letting that drive the current state analysis. Effectively we want to focus on the top priorities of the company first and then iterate the process for the next tier of priorities.This solves the problem of the is that the enterprise loosing focus on the assets they should be identifying at the right time.

An example of segmenting tiers is shown below.

Each enterprise will have a slightly different way of looking at this but the process should be similar. The tiers will also be implemented in waves. Meaning that you should perform a current state analysis in digestible chucks. I wouldn’t do more than 10 systems at any one time. This keeps a level of focus and increases the overall success of the effort. The only exception here is that as you move down the tiers you can get away with looking at more solutions at a given wave.

Obviously, when we look at implementing this model there is a great amount of detail that needs to be covered in the people, process and tools but this will give us a common way of thinking about the problem.

Without getting too much into process I will focus on where the industry is at with useful standards or tools that will help execute on a current state analysis. With that lets look at defining architectural models and how to build them.

To determine what a architectural model is or sometimes even just as important what an architecture model is not we need to start with a fundamental architecture taxonomy and ontology. Both of these terms are broad and have deep implications but if we keep it simple and say that an ontology that defines a consistent set of definitions on assets, concepts, abstraction and classifications. Then having a taxonomy will show how these pieces fit together in the context of architectural descriptions. This will help qualify the architectural models in the enterprise.

A good starter resource would be to look at IEEE 1471. I wrote a post about this (Making Sense of Architecture Standards) describing what IEEE 1471 is all about an how it contrasts with other standards. There is also a good article from the Open Group entitled Impact Assessment of IEEE 1471 on TOGAF that contrasts IEEE 1471 with their EA framework.

For more information on IEEE 1471 go to their web site at: http://www.iso-architecture.org/ieee-1471/index.html

There has also been some recent developments in this area as from the framework community. TOGAF 9 has released the start of what looks to be promising in two areas. If this continues to grow from the user community I think it could be very compelling.

1. Taxonomy and Ontology / Metamodel - I reference this in my post TOGAF 9 Release and Impressions where I talk about their metamodels and repository efforts. TOGAF is making strides in this area. Granted there still needs to be more work but it looks as if they are heading in the right direction. What’s positive about this even though it isn’t complete is that there is a ground swelling of support and community that is vested in this. Unlike other architectural standards, this one has a significant community that can help drive the standards forward. The side effect of this is that it becomes the defacto standard based on the shier amount of architects in that community thus having a level of uniformity in the industry when thinking about architectural information models.
2. Modeling and Notation – Now that Archimate is part of TOGAF there is now cohesion between the metamodel and the actual model with an architecture markup description language (ADML) and modeling notations.

Even though frameworks provide a lot of value be careful not to loose sight of the objectives. It is easy to do. Also, you may want to borrow from multiple frameworks as there are aspects of each that are unique in it’s own way. For example, Zachman provides a great way to group and classify information but you could use another framework like TOGAF to introduce decision making process to that, likewise with all the other frameworks.

All in all, a very exciting time for architects. There is a lot of new developments and opportunity to further the industry.

Other related posts that I have made externally on my blog that may help you out are listed below as well:

• Making Sense of Architecture Standards
• Pragmatic Approach to Describing Solution Architectures
• What is an Architecture Style?
• ArchiMate - The Emerging Architecture Modeling Standard?
• Architecture Modeling - IEEE 1471 has been adopted by ISO
• Can you Easily Compare EA Frameworks?
• TOGAF 9 Release and Impressions
• Creating a Enterprise Asset Roadmap Strategy
• Do Office Tools Still Play a Role in Architecture Design?
• Enterprise Architecture Analogy
• Obtaining Enterprise Architecture Metrics - Part 1
• Obtaining Enterprise Architecture Metrics - Part 2

There is also a Enterprise Architecture Toolkit that was developed that aid with some aspects of this:

• The Enterprise Architecture Toolkit
• Using the EATK to Capture Architecture Descriptions
• Japan's Largest Publisher talks about the Enterprise Architecture Toolkit (EATK)
• Why doesn't Microsoft have any EA Tools

Technorati Tags: Enterprise Architecture,Architecture,TOGAF,Current State Architecture Analysis,As-Is Architecture Analysis,IT Strategy,Zachman,IEEE 1471

Share this post :

The Value of Wisdom

As you can see I am playing a bit of catch up as TED has been over for awhile. Barry Schwartz makes a passionate call for "practical wisdom" as an antidote to a society gone mad with bureaucracy. He argues powerfully that rules often fail us, incentives often backfire, and practical, everyday wisdom will help rebuild our world.

Below is the video, Barry makes some very interesting points and I agree with them in an ideal world. But where this all falls apart is when you are the only ethical person in the organization. This is an all or nothing concept, unfortunately I think most corporate cultures are ready for this.

The Nemesis of Software Architecture

I had an interesting conversation with a friend of mine that resulted in some disagreements on root issues architects face. The topic of the Architect Nemesis came up. Where some of assertions were accurate it was still founded on a fundamental belief the we should correlate software architecture to the architecture of structures.

So what is the REAL Nemesis of Architecture?

Is it the engineer? Is it the templates and patterns? The CIO? NO…

I believe that the real nemesis of architecture here is in the name itself. Unfortunately we as an IT industry continue to compare ourselves with traditional architecture. Why is that? Well I think because it looks viable on the surface.

Here is why I think the Structural Architecture is different and why we shouldn’t compare the two (at least without having an understanding of where the analogy breaks down):

1. Maturity – traditional architecture has a head start of approx. 10,000 years old starting with Neolithic architecture that was around before 8000 BC. Since architecture has been around for such a long time there are clear lessons learned. A clear collection of knowledge, true repeatability and reuse, standardization and the creation of architectural styles.
2. History of Architecture – It is unfair to compare software architecture history to traditional architecture history. Contrasting with eras such as Classical –> Medieval –> Renaissance –> Modern architecture is looked at as a linear progression while it is far from a linear progression. As an example, before the fall of Rome there was running water and toilets in homes while it took close to 2,000 years to get that back. Another example is in South America where archeologists found ruminants of Nickel being created where that same feat wasn’t accomplished till the early 10th century. The history of architecture is a complex one driven by many forces and sometimes the great innovations are lost though time. The history of IT architecture is but a fraction compared to the architecture of structures.
3. Motives and Intent– The great architecture that are typically referenced in software architecture are by the Romans, the Greeks and occasionally the Egyptians. The problem with this is that the drivers to build these great architectures where often not the same drivers as for software architectures. These great architectures of ancient times were built based on personal ego, religion and conquest. Examples of this include: Via Appia roads in Rome (support conquest), Pantheon in Rome (ego/religious), Taj Mahal in India (religious), and Parthenon in Athens (religious). For software architecture the primary drivers are business drivers. Not how to sustain a legacy of an emperor or have a religious structure symbolize an ideology but to solve a set of problems for a particular point in time. Solutions are put into a portfolio because we know they will change (sometime radically).
4. Accountability Inherent – Building architects are accountable for there work when their specification fail while software architects are not. An example of this is the case of an architect stealing a design for the Freedom Tower or the example of MIT that sued well known architect for defective structures. There is clear accountability whereas I still haven’t heard of someone getting sued for copy & paste…
5. Models are Concrete – No ambiguity in a model from a building architect. Like the quote from George Box “all models are wrong, but some are useful”.  This resonates and is very true in the software industry. It is very common to see an outdated and obsolete model hanging outside a cubical that isn’t fully understood by the IT staff supporting. While you will never find an inaccurate city planner model. Two different worlds on what is acceptable from the models.
6. Accreditation and Certification -  Unlike the software architecture field, architects must be certified to work on an architectural project. This is vastly different in the software world. Often times the title of architect is given as a promotion to an engineer, a trendy title or just lack of understanding of what an architect really is. This leads to a level of ambiguity in the definition of what really is a software architect.

These are some initial points on the differences of these two vastly different professions. While they look relatively similar on paper they are different. Time and time again I see the correlation between these two professions and keep seeing the inaccuracies and false comparisons which I think leads to confusion and mistrust of our business leaders.

While I have been guilty of making these references when trying to convey ideas with something relatively similar. You maybe wondering if there are other parallels we can reference as software architects, I am not sure. How about the profession of an artist? Software architecture is more art than science, right? At least for now…

What are your thoughts?

Technorati Tags: Architecture

Share this post :