Interesting article (if a little under analysed) on InfoQ on Should EAs have an MBAs. Personally it's something I want to work towards, just once my kids are bit older :) This definitely helps establish credibility in the CxO space where an EA really needs to hold his own.

Interesting discussion on the TOGAF course this morning. Quite a good conversation across the room kicked off by the concept of a architecture board in TOGAF. Ideally you want your most senior executives on this forum, but the point is - do they care? do they have time? Do they really understand? In an organisation like the one I work for, it's very difficult to get senior management to care about EA let alone even understand it. If we had the right type of buy-in, then getting decisions made on architectural changes should become very straight forward. I don't even know if this is strictly architecture governance issue, it's really a wider IT governance issue that helps any IT capability move forwards. So I'm left thinking - if you don't have effective IT governance how can you effectively setup architecture governance?   

I'm currently on a TOGAF 9 course with my team of Enterprise Architects. I was certified a number of years ago in TOGAF 8 and it's really interesting to see how TOGAF 9 has come along in the last year. There are some excellent additions particularly around the content model. I am currently looking very strongly at using TOGAF 9 for the next EA framework at my company. It is answering so far some of my issues around TOGAF 8 as a comprehensive framework for Enterprise Architecture - which is good! 

This course is being put on Architecting the Enterprise.

Mauricio Freitas has posted an interesting set of thoughts on Internet censorship set to hit NZ shortly. I couldn't but help but comment on this one - because I believe the argument of fear of more censorship is not really strong enough to stop this type of initiative. I think it needs to be looked at through the lens of value for money and will it really make a difference for NZ. Have a look at the article - I've posted comments further down.

Another article from my reading today - the case for Enterprise Architects from CIO Mag. Some points that really resonate with me:

1. A CIO makes better use of an enterprise architect by having him or her focus on the technical viability of product solutions while determining their economic value to the business.
2. There are so many vendors pulling and tugging on IT organizations. EAs have to be a shield for that,- A voice of reason.
3. That person [EA] also has to gain the confidence of the senior leadership team. Execs must believe that the enterprise architect comprehends how the company works, where it wants to go and how technology helps or hinders. Then effective working relationships can bloom.

All of these points require senior management to have faith and trust in Enterprise Architects. It also requires that EAs have the opportunity to be involved in the planning of the business and any associated strategy exercises. This builds first hand knowledge and understanding of the issues facing senior management. The EA role is only as effective as the environment that supports and nutures his or her understanding of the wider business picture.

Another fascinating paragrpah is around moving temporarily (or crossing over) EAs into design roles (i.e. Solution Architect roles):

"In 2006, Grainger went live with a companywide SAP project-20 SAP modules and 30 additional applications that would touch 425 locations. To help guard against what could go wrong in a big-bang cutover, Ferrarell took his team of about 20 enterprise architects off their regular jobs and assigned them to design and integration roles on the SAP project. The SAP implementation was such an all-encompassing program that it made sense to re-purpose the enterprise architects into key roles in the project. Their broad business and technical knowledge made them very valuable team members, says Ferrarell. Grainger's senior business-side managers knew these architects and their business savvy firsthand, he explains. The trust was there, which helped get IT the intense cooperation needed during and after the complicated launch. Their architects played a significant role, not only in shaping the need for completion of the ERP project, but in ensuring its design would enable their business requirements. The SAP project succeeded, Ferrarell says, in part due to the institutional knowledge and business-IT translation skills the EAs brought to it."

It's my fundamental belief (in particular in a IT marketplace like New Zealand where resources are always scare) that having an EA getting involved in design on critical projects is extremely important. It brings a broader approach to an IT implementation that might otherwise be missed on a critical project breaking new ground.

I think the following section in the article sums it up about what an EA needs to do:

"An enterprise architect has to guard against getting too far removed to the management echelons and losing touch-and influence-with the technologists who design and code systems, Plant says. In other words, as much as an architect must build relationships with those outside IT, he also must maintain good relations with those inside IT who can make business plans into technology realities"

And don't underestimate the ability for an EA to execute:

'"Without the ability to execute, architects are going to constantly struggle with justifying their existence."

In my view to sum this all up - don't put EAs in a corner and get them to write strategies independent of technology and real business knowledge - use them for and develop their broad organisational knowledge and broad technical understanding.  This convergence of knowledge is how you nuture, grow and get great results out of a Enterprise Architect.

As per my recent blog post I have just run my course on Service Oriented Architecture twice in Novemeber. The feedback was extremely positive and it was a really enjoyable experience spending quality time on a topic I am very passionate about. I must thank all the participants on the course for making it a great experience for me. In that vein I've posted the overview section from the course book for others to look at it. If anyone is interested in having this course run for them, please don't hesitate to drop me a line on lukas AT svoboda DOT co DOT nz.

RealisingServiceOrientation-Overview.pdf (187.37 kb)

The concept of an Enterprise Architect vs. a Solution Architect vs. a Technical Architect. The following diagram is something I'm using in my travels to help with the understanding between the differences in architecture role. It based on some town planning/construction analogies to help non-IT people understand the differences.

Be interested in feedback from people on this one and how they see within their own environments.

EASATA.jpg (96.22 kb)

Today I was asked what the collective noun was for Architects.

I simply replied "A murder of Architects"!

I'm interested to hear from anyone that has successfully used their Enterprise Architecture tools for performing portfolio management. This is touted by several EA tools vendors, but I'm interested in feedback around this - especially why you wouldn't use a dedicated project portfolio management tool.

Sweating IT assets is important concept in IT Management and Enterprise Architecture. Many IT environments drive to replace and renew stuff before proper financial benefit has been fully realised. From an investment perspective sweating assets must be considered as a strategy and incorporated into lifecycle planning.  

On a lighter note - I think I just discovered the most extreme example I have ever seen of this - http://cbm8bit.com/ or http://58.6.118.18/. The tagline is "Manafacutured in 1982, Online Since Mar 2007". The site is a webserver actually running on a commodore 64 originally built in 1982. Goes to show, you can get more out of those old personal computers than you realised!