Enterprise Architecture

What is all the fuss about Cloud Computing?

Dave Oliver — Wed, 08 Apr 2009 01:36:08 GMT

Cloud computing is the buzzword of the moment . It seems that applying the "cloud" label is a real desire for a lot of people out there in the marketplace. This of course leads to the arguments about whether the "cloud" label is appropriate or just marketing spin.

Why on earth is Cloud Computing so appealing?

I think there are a lot of factors. I'll outline a few of the main ones below …

Trendy
To a certain extent delivering a cloud solution suggests that organisations are on the cutting edge of technology - and this hints that there is something worthwhile in the technology being delivered. Also the important important human-factor of the innate desire to follow fashion and trends.
Cost effective
One of the big claims of Cloud Computing is that it delivers the lowest cost of hardware possible. Not only are the servers uniform, they are designed in a way to scale broadly so that even large applications can be hosted without requiring special hardware. This is one of the reasons why Cloud Computing is sometimes called "Utility computing". That is, hardware that functions like a utility... it's just there.
High availability
Overall most cloud computing environments are designed to provide high availability - if one physical machine goes down, there is always another one to seamlessly pop in and pick up the load. As software-based services are being delivered via the cloud, this is a critical component to be concerned with. If you want to have 50,000,000 users, they have an expectation that their service will be there when they want it. Cloud computing generally helps manage this risk.
Operational Simplicity
It's a great relief to have someone else manage the infrastructure. Putting the hardware together is one thing, being stuck operating it forever is quite another. People who operate cloud computing farms generally have gotten the process down to a very efficient science. Of course this also helps out the cost profile, but it also means that the management is efficient. It is a big deal.
Financial Scalability
Cloud computing is often a "pay as you go" kind of deal. This minimizes the up-front costs and allows a small ISV to get into the game with a quality infrastructure that otherwise they might not be able to afford. When you pay by the CPU minute, then you can really trim down your costs to just what you are actually consuming. When it comes to matching costs to revenues (which you do hope to have), getting the costs down to actual with no extra is a nice deal.

Cons

It’s pretty clear that Cloud Computing as a concept has many problems to iron out before it can be considered a viable option by the Enterprise; the two mains ones are confidence and standards maturity.

The confidence problem centres around security concerns and belief. Questions such as, Who else can read my data when it is submitted to the Cloud? Are the claims of the benefits of Cloud computing really all to good to be true, what’s the catch?

It is also clear that the main players in Cloud Computing cannot agree on whether there should be standards right now or not. My feeling is that standards are usually better after a good dose of pragmatism and experience so as so many Cloud offers are still in beta this wouldn’t a prudent time.

There is also calls that having Standard’s bodies are little more than exclusive clubs designed to lock competitors out by using the ‘moral high-ground’ of standards as nothing more than a competitive edge, so the questions is whether Standards Bodies are really about benefitting the customer and the industry.

To add to the doubts how many Cloud services have published Service Level Agreements? I getting the feeling that this is still work in progress for many.

In Summary

Bottom line, using cloud computing is a sign of an advanced or very current application. It suggests scalability and availability. It is a cost efficient way to go for most ISVs. But it comes with a cost. You often need to look under the surface to discover if it really is of real benefit to you.

The potential is huge especially if not your organisation isn’t an Enterprise, this technology allows even a humble start-up to compete at the same scale as an established Enterprise.

With Cloud Computing many organisation such as Microsoft, HP and Amazon have committed significant sums on money and will be keen to have returns on their investments hence why the ‘hype-machine’ is going fall-tilt at the moment. The danger of this is that it will attract the same individuals that also hyped SOA that were quick to leave as potential wasn’t immediately realised damaging a perfectly viable architectural approach.

Interesting times for Cloud Computing, I will watch how things develop with interest.

Technorati tags: Cloud Computing

TOGAF 9 is now available !

Dave Oliver — Fri, 06 Feb 2009 01:49:23 GMT

There really has never been a better time to get into Enterprise Architecture as the global economic downturn means that smart companies will be looking at making efficiency savings through strategic implementations and process streamlining, identification of function duplication and better IT/business alignment. Enterprise Architecture is a hard thing to get off the ground so why try and re-invent the wheel and benefit from the experiences of others in many different organisations. Using a framework can help and this is what TOGAF is.

TOGAF is one of the most popular Enterprise Architecture frameworks for many different reasons and justifies a post on it's own. The latest version is an incremental step in it's evolution. Seemingly the Open Group have avoided far-reaching changes seen in previous versions and mainly sticking to enhancements and bringing other areas right uptodate.

In our organisation we have spend a great deal of time and effort working out our own metamodel that shows the independent relationships between business process, application, data and technology. Working this out can help in understanding the knock-on effects of changes implement any sort of change.

What I found particularly please was this metamodel does look very close to ours and show some things that we haven't considered so I'm very much looking forward to Enterprise Architecture software like CaseWise and Telelogic/IBM System Architect having these metamodel templates.

TOGAF's ADM now has additional guidance that will make developers cheer! As it has support for iterations so the ADM can be mapped to Agile development techniques such as XP.

Also additionally the ADM has guidance on

Applying different enterprise levels

Security architecture

Defining SOA governance

These are just a couple of things I've picked up on, I'm sure as I pick though there will be more that I will comment on, anyway the download is free so well worth having a look through whether and Enterprise Architect or not.

Technorati Tags: TOGAF,Enterprise Architecture

Which Enterprise Architecture Methodology do you use?

Dave Oliver — Sun, 10 Aug 2008 15: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 — Tue, 05 Aug 2008 05: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 — Sat, 26 Jul 2008 03: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 16: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 — Tue, 22 Jul 2008 02: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 23: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 21: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 — Thu, 05 Jun 2008 03: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?

Enterprise Architecture

What is all the fuss about Cloud Computing?

Trendy

Cost effective

High availability

Operational Simplicity

Financial Scalability

Cons

In Summary

TOGAF 9 is now available !

Which Enterprise Architecture Methodology do you use?

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

Enterprise Architecture Scheduler

Help your organisation to go Green, use Enterprise Architecture?

Lite EA is renamed Coherent EA

The first problem with Enterprise Architecture is the name!

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

Enterprise Architecture is a Joke