Architecture

The Open Groups SOA Ontology

Dave Oliver — Wed, 16 Jul 2008 20:51:52 GMT

The Open Group has recently released a draft version of a SOA ontology.

The Open Group has always had a mandate to help boundaryless information flow and the ontology (specification of conceptualisation) for SOA is a demonstration of just that. The ontology is written in the Web Ontology Language (OWL) defined by the World-Wide Web
Consortium and this for me is what makes it a hurdle to learn as it's not an intuitive meta-language but then is any? Perhaps if it wasn't for the graphical tools we would get stuck.

Open Group explains the benefits as:

1. It defines the concepts, terminology and semantics of SOA in both business and technical
terms, in order to:

Create a foundation for further work in domain-specific areas,
Enable communications between business and technical people,
Enhance the understanding of SOA concepts in the business and technical
communities, and
Provide a means to state problems and opportunities clearly and unambiguously
to promote mutual understanding.

2. It potentially contributes to model-driven SOA implementation. The ontology is designed for use by:

Business people, to give them a deeper understanding of SOA, and its use in the
enterprise;
Architects, as metadata for architectural artifacts; and
Architecture methodologists, as a component of SOA metamodels.

The full draft can be found here:

http://www.opengroup.org/projects/soa-ontology/doc.tpl?gdid=16940

After reviewing the draft I am left cold. My first opinion is that business will find this difficult to adopt in the same way they found UML difficult. Why because they are both coding languages, you may as well stick in a 'Print' command. The gap between logical design and executing code is a large as ever.

I still hold the belief that business and IT can only really align on the logical level. Business doesn't want to know about detail they will want to be abstracted away from that, this is actually a key SOA deliverable, just a very unspoken one, hence why REST services appeal. I believe that IT cannot handle business logic detail on it's own, so alignment between business and IT will come when hybrid groups formed of technologically minded users and business oriented IT exist to make, maintain and specialise in services that support their business area based on IT standards and underlying IT technologies and services.

Why I believe these groups need to exist is because business and IT can never align because they have very different goals and therefore different headings. Align the destination and the groups will align, not possible with business and IT as they are very different by reson d’etre. You can't marry creatures of different species. You can however translate and interface.

These groups do actually exist all over successful organisations they just lack boundary, form and recognition perhaps even by the very people that make them up. E.g. So you code in a Spreadsheet? So do you report to the Sales-Manager or Dev Team Leader?

Back to the Ontology, I think the Open Group need to ask a fundamental question, how does business see and understand logic? I really do think we need to revisit DSL's.

Technorati tags: DSL, SOA, Open Group, Ontology

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

Am I an Armchair Architect?

Dave Oliver — Thu, 12 Jun 2008 14:32:11 GMT

According to James McGovern, I probably am! Why? Because I don’t code … very often.

I don’t sit in an Ivory tower either making up my dictions via, Visio & Powerpoint. I think the key to being a good Architect is taking responsibility for designing a technical solution for business requirement with those who are going to built it, implement it, look after it and use it.

Making good technical decisions often means getting your hands dirty and trying afew things out, if that is writing code or testing a device or installing a server then whatever it takes. However, Architects shouldn’t try to be heroes and experts at technologies but have the courage to go form relationship and seek opinions of those that are, I think that this is the real point.

Ok, so an Architect therefore is more about diplomacy, relationships and pulling strings together, it isn’t an adversarial role, it’s point is to generate a solution to a business problem where everyone that is playing a technical role knows what they have to do.

Architects shouldn’t pretend to be experts in technologies, they should know when to leave things to the professionals and not to meddle and step back and let them do their jobs. Architects can’t keep up with best practices in all technologies, there isn’t enough hours in the day.

I believe that an Architects mindset has to be different from that of a lead developer or technical guru as an Architect has to be technically agnostic and objective, whilst a lead developer or guru has to be an expert in chosen technologies, can you see the difference? One is a specialist in a technology the other is a specialist in a practice that requires a passion for all technology. Often Architects are consider as the technology ‘point-man’ for a project and first point of call for all things ‘techie’ for a Project Manager.

So can an Architect specialise? Yes because technology is such a vast set of topics I can’t see how Architects can’t specialise in a field but it then becomes a balancing act where technology meets good architecture principles meets business direction, where as a developer or IT Pro need to become honed in their art whether they use an aspect of a technology at that moment in time or not, form opinions and even become bias, these are not luxuries an Architect can afford.

So if you are a developer or IT Pro and reading this and say … 'but I do that this stuff already', I would reply, 'good for you!' Because obviously you are capable of performing more than one role, don’t get the two confused.

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.

Enterprise Architecture: TOGAF Certification

Dave Oliver — Fri, 18 Apr 2008 10:38:16 GMT

Recently I attended a TOGAF certification course up in merry old London town run by Architecting the Enterprise (AtE). My certification should show up in the list of other 5000 odd architects that have passed in the next few weeks.

So what is TOGAF in a nutshell? Well it's a very generic architecture framework that helps build, in a non-prescriptive way, how to develop parts of an Enterprise Architecture capability.

Notice the caveats, 'very generic', 'non-prescriptive', 'develop parts'. What am saying is that if you want an idiots guide to implementing Enterprise Architecture in your organisation, this is not it and forget that quest because it doesn't exist! TOGAF sits a few levels above; it is the high-level plan that on specific subjects delves a little deeper with advice, guidance and best practice.

TOGAF is a product of the Open Group that is a vendor neutral IT standards organisation. You do get the impression that it's been designed by committee but try and get over any prejudices you may have on that score. There aren't that many other ways you can get many different and competing parties to agree on subjects.

TOGAF and the course initially left me feeling pretty annoyed, the reason being, I was left with more questions than answers. However, after sitting down in a quiet spot and analysing my thoughts I realised a few home truths,

More questions than answers is actually a good sign! Weighing it up, most of my questions are now smaller in scale, there are still a few big questions but not as many, so this is indeed a sign of 'thinking in progress'. TOGAF does give you a starting point, you have to fill-in not just the blanks but interpret how to make all elements work in your organisation, no two organisations are the same.
TOGAF isn't finished, it's pretty obvious it's a 'work in progress', some parts are more mature than others. My advice would be, have a go with what there is if you don't have a better equivalent, it's better than starting from scratch.
TOGAF is generic that means it is not going to cater for your individual organisation and circumstances neatly, there is a risk of 'if at all'. It is just another demonstration on how immature our industry is as a whole and really how few standards we have, there isn't a great deal of agreed collective thinking, just a lot of very similar problems. So get over the fact that you are going to need to do some thinking and work stuff out. TOGAF isn't an Enterprise Architecture flavoured Pot-Noddle.
Am I really going to make a better job of it than the Open Group? I admit that I can be arrogant buoyed by the confidence that no outsider is going to know my set of EA issues better than me. However many of my problems are similar and therefore are going to have similar solutions. It really does pay to have an open mind.

So am I a fan of TOGAF now? Well, I'm past the stage of 'it's better than nothing'. I've got to a point where I am beginning to respect it.

So is TOGAF better than the other frameworks? Well the answer to that is pretty simple, what does 'better' mean in your context? Microsoft, one could argue is a 'standards bodies neutral' vendor and has a very good article comparing the different Enterprise Architecture frameworks giving you a method to work out what is the most appropriate framework for your organisation.

For my organisation, the 'whether to use TOGAF' debate is still rumbling on but for my immediate colleagues and I have decided to run with it and see how far we get. Consequently, you are going to see TOGAF influencing this blog as I will report back my experiences as the journey continues.

Who Will Write Tomorrows Code?

Dave Oliver — Thu, 03 Apr 2008 07:54:17 GMT

The BBC's Bill Thompson in his recent blog post about the state of IT development in the UK has hit the nail on the head

"Universities have seen applications for computer science degrees fall off, schools do not encourage students to do computing at GCSE and A Level and primary school children are trained as users not as programmers."

Recent reports from the CBI (Confederation of British Industry) and CEBR (Centre for Economics and Business Research) indicate that skilled migration workers, specifically in IT and Telco sectors, will significantly contribute to the UK economy and be instrumental in its future growth. So why isn't this capability grown here? It's almost like government and business has actually given up as the direct labour cost is cheaper else where. What I find fascinating is the in-direct costs such as longer lead-times aren't measured so we have no idea how much of an impact that is having or how much of a competitive advantage we are giving away. E-Petition on the Number 10 UK Government website about providing better support for out of work software developers and IT workers adequately demonstrates the lack of interest for issues effecting developers by the lack of signatories where some more inconsequential petitions have a significant amount more. The diminishing amount of UK developers is just not seen as an issue of national concern when it is pretty clear that our economy utterly relies on technology.

I feel this is a narrow sighted view not because I'm a complete xenophobe but as recent evidence suggests the cost of living is going up in the countries we are typically out-sourcing to, with rising inflation meaning wages will rise as a consequence. So as a prediction, cheaper offshore workforces are only going to be true for a period of time. Perhaps in as little as 10 years, wages will rise to a comparable rate between here and aboard nullifying the advantage of having an offshore but will we have sufficient development capability left in the UK to meet our economic needs or let it dwindle leaving us little choice.

So if we want to avoid this future wouldn't it seem prudent to incourage our young to take up carrers in computing now as protection for our future or as another option encourage IT workers from outside to settle here? Whatever option we chose, I believe we cannot afford to allow our development capability to diminish as it is a core skill which our economy does and will continue to depend.

Managing your Mind. Mindmaps, a handy tool for the Enterprise Architect.

Dave Oliver — Mon, 10 Mar 2008 14:46:17 GMT

OK, so techniques for managing our time are common place such as calendars and to-do lists. But what about managing your thinking?

Being an Architect is a practice, not a process, so arguable the most important tool we have is our brain as it is our central repository for knowledge and logic but it's not like a computer. Often useful information comes flowing out it, almost randomly in no particular order that's if your lucky. Sometime the brains requires some exploration and provocation to tease that useful nugget of information out. All of which is pretty hard to do just writing lists on a pieces of paper, talking over with colleagues, or more often than not, writing straight into Word or an email.

As you can imagine this was all to ad-hoc for me, I need a technique to get my thinking in order, structure my thinking and capture my areas in away that was easy to understand and communication that allowed continued refinement.

Richard and I discovered a technique called Mindmaps many years back, which is literally creating a list of items around a central theme that documents the relationship between items just be drawing a line. So Mindmaps can basically look like a morphing spider.

Mindmaps are a simple way to explore and capture ideas fully. My problem with them was the application. Drawing it on a white-board or piece of paper is messy as these things change a great deal in their development. A drawing system on a computer would be a logical answer and indeed there is a vibrant market for such tools. However only recently have I discovered that these systems have become very good indeed which makes using the Mindmap a viable option for structuring your thinking.

The market is dominated by two options,

The open-source tool and market leading tool FreeMind
Microsoft Visio as part of the Flowchart template which comes with the tool.

Both of which are great places to start but they both fundamentally suck in different ways which left me thinking that creating Mindmaps isn't as a pleasant experience as it could be. If you want to explore creating Mindmaps, don't start with these two, they can colour your judgement of Mindmaps and it's usefulness.

What about some of the other tools on the market then?

ConceptDraw is a nice tool and has a Mac version, the basic offering is also free. It is however a real drawing tool and doesn't assist you as far in making Mindmaps as other tools do.
Personal Brain is a wonderfully wacky tool that is mindmapping for geeks that have no problem with seeing complexity. I would live in fear of giving this tool to a non-geek but it's great for exploring problems from different angles. Again there is a Mac version. Using this tool did at times feel like playing a computer game. Fun but I would scare people to death with it.
Mind42 is Web 2.0 answer for Mindmapping, with a web-based tool that specialises in collaboration. At the moment it is a free to use and doesn't have as many features as some other products, but worth a try.
Other tools worth mentioning are Matchware's OpenMind, VisualMind, Mindmapper, etc ... you get the picture it is a large and vibrant market. All of which are worth downloading the free trials and exploring all of which I did and had a great deal of fun with...

However there is a outright winner IMHO and that is Mindjet Mindmanager Pro 7 which is a tool that is feature rich with the most common ones being easy to use. The tool balances the feature list with a very high userability level. The level of intuition is natural allowing the mindmap creation process to flow. The Office 2007 style toolbar is a genius addition to a product like this as seeing changes before commiting to them is a god-send. There is also a Mac version, a free-viewer and a great deal of pre-made Mindmaps ready for you to customise to your individual situation saving time.

The selling features are,

The high level of polish, it's not buggy. it's intuitive and consistent through-out.
The easy of use! Intuition features like 'Drag and Drop' shows that a lot of thought and care have gone into this tool.
Item Notes editor. Writing notes on items and sub items should be a standard thing you would want to do. Infact I think you will spend most of your time writing notes and having a full-featured Live-Writer like editor is just brilliant.
Interaction with Microsoft Office. The chances are you don't want all your work trapped in any one tool and will want the information you have captured in it exportable to other tools. Even better if it transforms the content to fit appropriate the tool it's going to. This is the utter genius part of Mindmanager Pro, this realisation. Take for example the export to Microsoft Word. The item and sub items become headings and sub-headings and the attached notes become the text. This does indeed increase the chances of you sending out a fully-formed document from export.
It's not really expensive, I want to buy the Lite version for use at home to help write this blog. It's not much more in price than an Xbox 360 game.

Now the words of caution,

Mindmapping isn't a skill for everyone, it's a personal preference, some people get on just fine with OneNote, notepad or even pen and whiteboard and/or paper. So don't expect everyone to use mindmaps.
Mindmapping isn't the only technique you can use to explore, capture and structure what's going on in your mind, after all Edward de Bono and countless other have been writing about different methods for years. So go explore and experiment and find a technique that works with you. But don't sit there and not use anything!

Mindmapping has become an essential part of my role and Mindjets Mindmanager is my weapon of choice.

Do you like or loath Gartner?

Dave Oliver — Wed, 13 Feb 2008 22:59:39 GMT

James Govern posses an interesting question I have often wondered “By nature or nurture, architects fall into two camps regarding their general attitude towards abstractions: Believers and Non-Believers.”

Well James, I see your point but I don’t believe that I fall into either of those camps. I treat abstractions as a means to an end and try and keep them in context. The thing with percentages is that your organization may fit into the smaller side of the percentage divide and not in with the mainstream, i.e. “Most companies that have adopted X have benefited” you know the typical analysis company slogan.

Being a good architect means that you must be objective and use Gartner et al only to your benefit quoting them only when it’s beneficial to PR/sell your cause but it is important to understand how an answer was achieved.

For example, it’s rubbish to say that 90% of women say a brand of wrinkle reduction cream works when only 53 people are involved in the survey but however if 53,000 people were involved that would be a different story!

As an Architect I think it’s important to keep an open-mind and choose your weapons carefully.

Anyway, Gartner is a commercial company that’s main money spinner is credible output. So if you don’t like something, challenge them! I’m surprised why more people don’t.

Book Review: SOA Approach to Integration: by Ramesh Loganathan, Poornachandra Sarang, Frank Jennings, Matjaz Juric : Published by Packt Publishing

Dave Oliver — Mon, 31 Dec 2007 18:44:12 GMT

Selling the theory for SOA is pretty easy, the execution is harder because technically it isn't actually a very simple thing to do, let alone the changing of the structure of your IT organisation to house-keep.

The book SOA Approach to Integration is aimed fairly and squarely at the Architect and Senior Developer who has the job of designing and implementing SOA technical level. The book is very resolute in keeping a strong focus on the technology and pleasantly realises that successful integration needs to take place across technological boundaries. Seems pretty obvious but I have a whole host of SOA books gathering dust because they lean heavily towards one technology and one approach. This book refreshingly avoids that, even avoid tasty new SOA areas such as composite applications and REST.

The book takes the reader through the basic principles using patterns to demonstrate many classic integration techniques. Sample code in Java and .Net and takes you through the interoperability story between these two mainstream development environments. Sadly this is where I found my first real criticism of the book, the book does not cover Microsoft .Net 3.0 and WCF or indeed any of the work performed by the Open SOA group such as SCA and SDO. I know that both technology frameworks are on version 1 but developers will be keen to use these frameworks and will feel license to do so as they aren't in beta.

One of the major problems with writing highly technical books is communicating complex points, this isn't very easy without diagrams. The book excels here because it's stuffed full of them, 92 diagrams (or there about's) and many a point sails across because of them.

Most of my list of key SOA points are covered but the books core strengths are BPEL, XML Schema's, Web Services and establishing an ESB, subjects it deals with a high degree of expertise second to none. However specific applications are not mentioned much but one of the clear aims of this book is to stay tech-neutral and keep to the keys points and I would like to thank the authors for that. It is a rare treat to see advice separate from opinion.

So would I use this book to advise me on my next SOA project? Most certainly yes! I can see it being my companion to many a design meeting and delving into it's pages for nuggets of advice. However comprehensive this book is not, thankfully it would therefore become a huge unwieldy tome and no use to man nor beast so I thank the authors that they keep things brief and to the point and at 351 pages not something that is going to weigh your brief-case down.

One very small point, I have been reading this book over Christmas and not one person thought to pick me up for reading a 'techie book' I suspect this is down to rather delightful butterfly on the cover. I wonder how many times that saved me from washing up?

Book: SOA Approach to Integration

Authors: Poornachandra Sarang, Frank Jennings, Matjaz Juric, Ramesh Loganathan

Publisher: Packt Publishing

Here from Amazon UK , Barnes and Noble & Packt

Technorati tags: SOA, Integration, BPEL, XML Schemas, Web Services, ESB, PackT Publishing