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?   

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.

Today I've just finishing doing the capital planning aspect of our budget round for the financial year 2011 for the IS department I work in.

The process entails consolidating and collating a lot of information, mostly from many of our technical people. The broad list of items then goes through a 3 stage process of prioritisation and refinement until we have a properly ranked and classified set of items that allow the creation of a sensible capex plan. As part of the process the EAs in my team take an initial lead on making sure the information is being put together by the stakeholders and then I get the managers across the department together to debate the relative rankings and merit of the items. Lastly once I've completed this process, the list is then handed over to our commercial manager to be turned into a document for submission to senior management.

I use a fairly extensive SharePoint list I've developed over time, plus a documented ranking process that takes into account our governance mechanisms around chargeback to our business units. I'd prefer to use some sort of portfolio tools so I could persist and manage the business rules I've built into this process over time. I could see a portfolio tool allowing quarterly updates and forcasts to be better reviewed in the light of the original financial plans.

I'm also acutely aware a lot of EAs don't get involved in processes like this - and I think they should. I personally enjoy running the process as I get a vary clear picture of where we have come from and where our investment profile is going. Especially after being involved with 3 rounds of financial planning over the last 2 and a bit years!

Questions for readers of this blog:

1. Does your financial capital planning for IS follow a similar process?
2. How detailed do you go with ranking?
3. Are your EAs involved and how heavily?
4. Do you use a portfolio management tool to do this? If so, what and why?

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 part of my ongoing collaboration with Brightstar, we are putting on a course around Service Orientated Architecture. I ran this course out of Auckland and Wellington 3 years ago and got extremely positive results and feedback.

The marketing blurb is as follows:

"What is Service-Orientation (or “Service Oriented Architecture”) and how does create value out of your IT Investment?

Although many aspects of Service-Orientation are not new idea in themselves, Service-Orientation is a new way to organise and manage your information systems whether in-sourced, cloud based or using a combination of deployment models.  Service-Orientation as a guiding concept provides an infrastructure to establish, manage and stream line IT systems. It provides the disciple to manage process flows between systems.

Based on established standards, Service-Orientation is set to fundamentally create a new breed of information technology assets and will change the nature of IT investment and benefit realization.

Realising Service-Orientation has been designed with a well-rounded overview of the current industry and marketplace, covering concepts, models, relevant NZ case studies and pitfalls associated with implementing SOA. Prescriptive guidance and lots of interactive discussions have been weaved into the course to ensure your learning experience enables you to apply and develop your new understanding."

For more information and to look at registering, please go to the Brightstar Website. If you want to know more from me personal please contact me on lukas AT svoboda dot co dot nz.

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!