Enterprise Architecture

Which Enterprise Architecture Methodology do you use?

Dave Oliver — Sun, 10 Aug 2008 09:24:00 GMT

There is a bewildering array of Enterprise Architecture methodologies so it will be of great interest to me to find out which one people are actually using, if at all.

So to find out, I have put together a pick poll so please take the two minutes and leave your choice.

You get a chance to select up to 3 options because I suspect that people are using a combination of more than once approach, rather than following one prescriptively.

This is purely for interest purposes, I'm not going to use this data for marketing. I'm also sure it's not particularly scientific but it is chance for you to express your opinion.

The poll is here on the EnterpriseArchitecture.co.uk forum.

Technorati tags: Enterprise Architecture

Enterprise Architecture: Data has a life and a death but should it?

Dave Oliver — Mon, 04 Aug 2008 23:53:45 GMT

I have this belief that understanding how to manage time is an essential task of Enterprise Architecture but oddly this is a principle that isn't spoken about much, if at all. Oddly some Enterprise Architecture software tools only seem to provide time management tools for software support life cycles. Hence a previous post that went in some way to start the debate with a mindmap to capture and categorise the elements that Enterprise Architecture would be interested in.

After reviewing this mindmap it became apparent to me that allot of data has a life. Take for example financially data, it has to be kept for x number of years then archived and/or deleted.

If it is lucky enough to get archived the data format that it is held in is going to get old and as technology moves on at a pace we soon won't have the equipment available to read it. But who cares about old data? Well actually as any historian will tells you, everyone should! Data held in electronic formats is the equivalent of ledgers and manuals written out by hand, printed or typed in previous times that provided a valuable history allowing reviews to re-examine what was going on so lessons could be learnt and history, in effect, didn't have the opportunity of repeat itself as previous mistakes made could be avoided in future.

Take for example the current 'Credit Crunch', could we better understand more about the lead up to previous economic down-turns if we had access to more data from those times than just the summaries and analysis performed at the time without the benefit of using the knowledge and tools we have now? Yes, this way we could put in better economic markers allowing a greater degree of fine-tuning and less likely to lose large amounts of money on a bad idea constantly hidden, because it take such a long time to reveal itself and kicking us up the butt.

So old electronic data siting on a tape real or floppy disk in a store-cupboard is a waste as it provides insight into your organisations history, how did it get to where it got to today? What mistakes did it make? What did it do very right? All this information is more than just useful to historians but can actually become a handy revenue stream as Analysis companies will pay good money to write case-studies and books about what your organisation did right which they can package up and sell that doesn't do your business reputation any harm whatsoever, all helping the share-price. Also allows you to discover if faltering area of your business every did work right allowing you to play back to when it started going wrong. Also when mistakes are made with more access to more data won't it be easier to spot trends?

With data storage being so ridiculously cheap it could be well worth dusting off that old media and loading and transforming it into something that can be used. Yes, this all will take time and where exactly is the ROI? Well, I think this will actually be an easy sell as many friends that work in finance have spoke to me that they wished they still had access to old data, so I don't think this will be a hard fight.

I believe that data should never be deleted and if it is archived will then it should be into systems where it can easily be retrieved that are kept up to date, invested in and brought forward.

The fly in the ointment is software vendors and their constant games to provide some kind of lock-in or incentive to upgrade. These tactics will effect the ability to retrieve historical data so we must look to either taking matters into our own hands and transforming data to vendor neutral data formats or avoid software vendors that use proprietary data formats all-together. We need to pick our vendors wisely and put format neutrality into our 'must-have' requirements rather than 'nice-to-have'.

When you think about this, it is a serious issue, an elephant in the room that no-one sees.

Technorati tags: Enterprise Architecture, Data

Enterprise Architecture Scheduler

Dave Oliver — Fri, 25 Jul 2008 21:36:52 GMT

Many Enterprise Architecture methodologies talk about the management of time but I haven't found one that tells you how to do to that. For a practice that is about understanding the now and the step to achieving the to be, I find this an amazing oversight.

Anyway, so what I decided to do was to have a go at capturing all the relevant timing information that an Enterprise Architect would be interested in. Hence the attached Mindmap, which you can click into.

If you prefer you can come and join in the discussion on the EnterpriseArchitect.co.uk Forum.

Technorati tags: Enterprise Architecture

Help your organisation to go Green, use Enterprise Architecture?

Dave Oliver — Thu, 24 Jul 2008 10:33:01 GMT

Paul Homan recently commented on Green EA which set my mind thinking ... 'being more Green' is a strategic ambition and what is the process and practice for generating strategic change? Enterprise Architecture! When EA's are struggling to find some ROI reason to justify their existence in the economic down-turn amazingly one of the main ROI reasons is one of the biggest issues of our time as the 'Return' doesn't literally mean monetary and also doesn't necessarily mean more? ... it can also mean less, as in less carbon release, less waste produced and less energy used.

Often companies are looking for quick, hand-to-mouth change to make an immediate impact but often these changes are to radical or not radical enough, either way will need draconian measures to keep them in effect. Good strategic change happens in steps and not sweeps.

A good example is the profile of electricity consumption throughout the day. As you can see from the graph of total electricity generated in the UK in MW over half hour periods taken from today's Elexon's BMReports website yesterdays power consumption profile is similar to today's.

Much of the electricity is generated by coal and gas power-stations, by reducing the amount of electricity generated by these power-stations is the goal.

The two pronged attack is,

1) Reduce the overall demand for electricity

2) Replace whole or inpart the electricity generated by coal and gas power-stations with generation methods that do not give off large amounts of green-house gases.

I should say that many would like to take this go a step further and use generation methods than have little environmental impact such as wind, wave, solar and thermal to name but a few. I personally love this but am aware that to get here a lot more research and investment from everyone is required.

Whilst I'm on the subject we may as well talk about nuclear. Here in the UK we have had a good safety record with nuclear mainly due to the very British safety obsessive attitude brought about by culture. Nuclear cannot ramp up or ramp down in energy production as fast as coal or gas so is used for the large volume sustained underlying amounts of energy which is called the Base-load. The idea in the UK is to reduce the amount of Base-load produced by Gas and Coal and replace it with nuclear.

My very personal view is that I am happy about this as long as nuclear itself is a medium term answer and will itself be replaced by other forms when they are suitably advanced enough and man enough for the job. So whether you believe in global warming or not it does make common sense to reduce the amount of CO2 in the atmosphere to improve air-quality and it does make sense to reduce the amount of electricity we consume. These are noble ambitions no matter your political stance.

Anyway we haven't strayed away from the point, just merely demonstrated it. Good strategy comes from providing goals and coming up with board solutions which launches initiatives, then programmes of work, then projects. All the time testing whether things are right and have the strength to stop them when they are wrong, even testing whether the strategy is right. However the basic misnomer is that strategy is a plan.

So can you imagine the chaos if the Government decided to solve the problem by rationing electricity? Ok so this wouldn't happen because Government understands the criticality and how much is dependent on electricity, the steer is that it is obvious how much electricity is relied upon. We as Enterprise Architects could learn many lessons then successfully communicate them about what is the critically of things purely by understanding what is dependent on them.

The challenge is that Enterprise Architects really do need to become the green champions of our organisations by understanding what is consumed and wasted, then working with the business to decided on goals then formulate strategies and place in measures and governance to ensure these strategies and tested and the goals met. We are after all ideally placed to take on this responsibility so we shouldn't hide from it.

So here is my challenge to all Architects that have blogs, write about going green as we need to spread the message that solving these problems is everyone's responsibility.

Technorati tags: Enterprise Architecture

Lite EA is renamed Coherent EA

Dave Oliver — Mon, 21 Jul 2008 20:57:29 GMT

John Wu is a good guy. Out of respect for Fenix Theuerkorn and his work on Lightweight Enterprise Architecture, John has decided to rename his EA Methodology from LiteEA To Coherent EA.

Coherent EA is a actually a better, more descriptive name for John’s work IMHO and as a regular contributor to the ITToolbox conversations his methodology has the benefit of faster development from genuine experience than most of the others I could mention.

I certainly have benefited from Coherent EA in the past and think that it is a great resource, so I for one will be updating my book-marks.

The first problem with Enterprise Architecture is the name!

Dave Oliver — Wed, 25 Jun 2008 17:32:34 GMT

Job titles are often effortless in their descriptiveness. Project Manager, Business Analyst, System Tester and .Net Developer are good examples because the subject is concise and the predicate modifies successfully, all meaning some semblance of what a person does can be derived from it.

However with 'Enterprise Architecture' and 'Enterprise Architect' it’s not entirely obvious what the position is and what someone holding that position does, inevitably leading to the need for further description which predictably stumbles into the second problem, the woefully dire and contrasting descriptions of that we do that litter almost every Enterprise Architecture methodology and practitioners blog. No wonder the meaning is different from organisation to organisation and therefore what an Enterprise Architect does (or doesn’t) and get involved in. Inconclusion the Enterprise Architect is hindered from the get-go.

So what are the solution options?

1) Educate everyone on Enterprise Architecture – Many are hoping that time and tide will eventually solve this one but without a united vision I fear that this is little more than a hope.

2) Break-up Enterprise Architecture into it’s constituent parts and give each one an individual role – More realistic as this ensure that the activities under Enterprise Architecture have individual focus and therefore are likely to happen rather than get lost, diluted or ignored.

What do you think?

Technorati tags: Enterprise Architecture

'So what is Enterprise Architecture?' ... why can't we agree on a definition and the risk if we can't.

Dave Oliver — Fri, 06 Jun 2008 15:06:14 GMT

Ask almost any Enterprise Architect and more seriously anyone who has to work with Enterprise Architects, what Enterprise Architecture is? and I guarantee you will get a great number of differing responses. Yes, obviously you will get a number that that only describe their individual relationship and won't fully encompass the role but then again will they know the rest of what an Enterprise Architect can do? ... and if they don't know and they are a manager could they make a mistake and create another group to perform one of the tasks under the EA remit? Surely this kind of thing doesn't happen in a well managed Enterprise? Well if that was the case then the 'well managed' Enterprise wouldn't need EA's!?

So where do you go for the answer? TOGAF? Zachman? Fellow EA's? IEEE 1471-2000? ... and I'm perfectly sure that every EA's that has a blog has had a crack at the definition as well!

So why can't we all 'sing from the same hymn sheet?' What will need to happen so we all are?

I think I need to muse on this question a bit more.

Whilst intrinsically we all feel strongly about EA providing a strategic thinking overview to help organisations make informed business decisions, we battle to make EA pragmatic. We also battle to sell the value of EA to senior business managers and even make the value clear to our IT and business colleagues.

Moreover, even if organisations believe in EA, many organisations simply cannot afford the time and resources to establish an EA framework. On that gloomy note you might conclude that we are all wasting our time attempting to carve out careers in EA.

One way could be helping our IT colleagues to develop a mature Operations and Support Services (OSS) Architecture. Another could be helping our teams improve IT Governance.

At each step along the way we must deliver value to the business in real terms such as:
- reducing costs
- increasing revenues
- reducing time-to-market
- improving service levels, or
- reducing business risks

Before organisations will allow us to do grander things we enterprise architects must increase our credibility. The only way to do this is to progressively solve business problems for people along the way. Consistently demonstrating real business value bottom-up as well as top-down.

Enterprise Architecture is a Joke

Dave Oliver — Wed, 04 Jun 2008 21:19:22 GMT

Jeff Schneider over at Momentumsi has stirred up some EA’s with his post Why Enterprise Architecture is a Joke in particular John McGovern with this post which Jeff Schneider replied to with this.

In Jeff's post, point 3 hit home the most ...

"3. Silo Organizations promote Silo Funding. Many EA's never had a chance. They live in organizations that fund everything according to business silo's. Then, the EA is expected to bridge the silos with nickle and dime funding. Their inability to perform Herculean change (multi-channel, master data, cross-organizational BPM, master SOA services) has many of them designated as cops with no gun, just a good flashlight."

I'm working in an organisation that is just beginning it's journey in Enterprise Architect, I'm sure Paul Homan wrote this blog post after working with us. The point I'm making is that Enterprise Architect will go through various stages of maturity before it fulfils it's potential, however I will concede that many political factors will take there toll on the fledgling EA initiative but sometime it is frustrating when people in command make bad decisions. Lions lead by Donkey's does springs to mind.

I know there is frustration being a Enterprise Architect but I honestly believe that we have to start to help ourselves by learning afew lessons in making good PR. We found that by producing small deliverables (a few handy pattern here, a CBM of describing that business area there) regularly and repeatedly and rapping it up in a minor version release constantly re-enforces the message that something is happening. In small manageable chunks trickles will turn into floods and overtime becomes embedded into the culture of your organisation as more people use the stuff the EA team has made in influenced.

There is no point in taking pot-shots at Zachman or TOGAF. If you really have no clue on where to start then taking a course on either really will help you get some idea. Yes, they are generic, well derrrrrrrr, so get over that there is no manual because the whole thing is reasonably new, Even title 'Enterprise Architecture' is just a banner for many different techniques, disciplines and practices, hence why there is no definitive what is ... ? Enterprise Architecture is The 'generic bucket' meaning we will be having this conversation over again.

Which leads me to this point ...

"2. Bad Application Architects got promoted to be bad Enterprise Architects. Although this isn't a universal truth, I've witnessed my fair share of it. Those who can't architect do PowerPoint."

I was development Team Leader before I became an EA and I admit that it wasn't a job I actually liked or was good at, I liked the strategy part but not the rest. However it didn't take me long to realise that the IT industry is evolving so new roles appear all the time to manage the ever increasing complexities the industry is continuing to spawn. The upshot being I could do more of the stuff I enjoy and good at because the industry has spawned enough new activities to get worried about to justify a whole job role to cover it and make sure it is done. It does make me laugh when you hear, Developers go on about who needs Business Analysts or Architects, it's precisely for the reason that there aren't enough hours in the day and analysis jobs weren't happening that brought rise to these new roles in the first place!

Anyway, so if you don't actually know how to grow an Enterprise Architect properly you are going to get afew duds, so what does an Enterprise Architect look like? ... and what makes a good one?

Glossary of Terms for Architects

Dave Oliver — Mon, 02 Jun 2008 21:51:30 GMT

Graham Berrisford has set aside part of his website with a project to create a Glossary of Terms for Enterprise and Solution Architects.

I think this is a simple and fantastic idea as discovering what words and acronyms mean is actually a pain in the neck. Yes, Wikipedia is great but sometimes a simple sentence rather than a full page of explanation is all that is required. Also, acronyms like 'MDA' have several meanings depending on context so it is handy to have a resource that is from the Architects point of view.

The resource is free and open to anybody to suggest changes.

Enterprise Architecture: The Disconnect Between Theory and Reality

Dave Oliver — Thu, 01 May 2008 16:45:16 GMT

I took up Mike Walkers offer in the previous posts comment section to look at his post entitled Making Sense of Architecture Standards and found it an ideal steer on what standards are out there, where they are positioned, how they fit together and who will use them and when to use them.

However, what soon dawned on me was that the disconnect between theory and particular context is huge! Many of the standards are no more than helpful steers that as yet don't offer that distilled level of knowledge that is the mechanics and the moving parts of a functional EA initiative, this you have to make yourself. This perhaps may explain why only larger organisations can take the Enterprise Architecture plunge as the amount of work needed to turn high level theory into a userable practice for individual circumstances will take super-human effects and a deal of time. All of which only the larger of organisation can afford.

Taking Henry T Ford's principle of creating masters and experts of easily manageable domains and string them together into a production line is something that as yet hasn't happened in the Enterprise Architects space, we are still the equivalent of the master craftsman in a cottage industry. When Tim Berners-Lee talks about the immaturity of the IT industry, he need not look any further than the Enterprise Architecture for a shining example of that.

One of the great things about the Open Group is the forums where Enterprise Architects can meet and discuss but it is a club that is not free to join, there is a fee. The fee is large enough to mean a justification case and not every organisation, specially now, can make a case stick, especially if the core industry they are in isn't IT. The upshot is that the Open Group seems to have more than it's fair share of IT companies and weirdly not Microsoft which for all the talking is still the one of the biggest players in the game. Like or loath them, you can't ignore them and no-doubt nor does your business.

So where do Enterprise Architects meet then? I've found a whole bunch of EA's at ITToolbox and would be curious to find some more hiding places of the lesser spotted Enterprise Architect. At least here the questions I would naturally ask have at least been tackled in some way shape or form and afew kind souls even have offered their particular solutions up to the web for inspection by others and relish the scrutiny of their peers. This all adds up to meaningful long running conversation that can be followed and inputted into by all, which seems to be the nature of creation these days on the web, i.e. results by collaboration.

In the past an industry or practice had to rely on thought leadership and some inspired person to drive through change and create a following. John Zachman has tried to do this with the self-titled framework. I think in the connected world, this approach has a limited time left. The technology is here to allow hundreds, if not thousands of individuals to help build solutions, an individual making their little piece and letting others refine it. Open Source has show us that this can be done. I see no reasons why methodologies can't be constructed in a similar fashion?

In this day and age where reputations have to be earnt and transparency is the only sure-fire way to credibility and the price-tag has got to be free, thought leaders and committees have a limited appeal and therefore a limited reach so for a methodologies or frameworks to succeed will depend on whether they can be constructed in the new standard. If not, then we will all be in our cottage's or 'silo' for sometime to come, finding our individual solution to a common problems and interpreting the things like TOGAF's ADM a 1000's times over. Just think about all that wasted 'brain-time', when it could be spent putting the touches to a small part of an industry grown common solution, owned by no-one but everyone. There's a thought.