More stuff I learned at SAP TechEd 09

So another head filling day at SAP TechEd 09 in Pheonix.

The list of things I have learned today is shown below J

1. It is possible in WebDynpro 7.2, to make it not look like WebDynpro – So we can have the best of a framework that is robust and have support for more standards and plugins – iFrame, Silverlight and Flash
   
2. The nightmare of destinations breeding in CE goes away in CE 7.1.1 – Long live Service Groups
   
3. Peanut butter bagels is a great way to wake up in the morning – best plan an extra long run at the weekend
   
4. Composite Applications give great flexibility – but the downside is that if you don't think about what you are doing that flexibility will let you develop a mess – hmmm how does SAP prevent lots of failed Composite Projects ? Specialist Partners J
   
5. Most people you meet don't think that you can develop a composite application in a day – when you show them you can they get really excited.
   
6. NetWeaver mobile 7.1 has loads of features to help you manage thousands of mobile device – it also runs on ABAP NetWeaver AS 7.1 so that is another flavour of AS to have in the stable
   
7. Lots of people want to have one server at one version running everything (as they think it will be "simple"– people need to change the way they think now we have blades and clouds and stuff like that – which allow flexibility on deployment and management
   
8. Using the CAF Services builder you can created hundreds of service end points really really quickly – the services are breeding like rabbits
   

So now off to Process Slam and Hacker Night.....my head is starting to overflow.

Stuff I learned at SAP TechEd09 Today

I have just finished the first day of SAP TechEd 09 and I thought I would share what I learned today.

1. SAP TechEd is very big – over 450 session over 4 days
   
2. SAP NetWeaver BPM 7.2 does allow you to create fully fledged Composite Applications without writing a line of code – which was a great feeling
   
3. You need to understand what SAP have been doing with SOA over the past 5 years to make sense of the "new stuff" – so good job I do J
   
4. Early exponential growth looks just like linear growth – the trick is spotting the things that will go exponential !
   
5. SAP are filling the "missing link" of SOA by delivering a "Local Event Infrastructure" (LEI) – so goodbye SOA and hello Event Driven Architecture (EDA)
   
6. The infrastructure that supports these applications is really really clever – you need to understand what it is doing and how to tune it to make your systems fly
   
7. The SAP and Business Objects merge is going well and given another 12-18 months will deliver some really amazing stuff – so spend this time making sure your backend house is in order – so you don't end up putting lip stick on a pig
   
8. DemoJam delivered some really fun applications some of which might actually be useful – go Yowie !!
   

Oh and I help one guy configure service end points and he was really pleased - nice to get thanked J

Not bad for one day....hope tomorrow is a good.

Is your project team ready for web 2.0 ?

Now don't take this blog the wrong way, I am a big supporter of the things web 2.0 can bring to teams working together, but before you launch your team on a web 2.0 collaborative fest, make sure that you have enabled them with the right tools and training. Below are a couple of pointers that should help you to prepare your teams :-

Make sure that everyone in your teams can access the tools you want to use

Many web 2.0 tools assume quite a high level of browser and machine specification before you can even logon, if any members of your team do not have at least the minimum that is required this will lead to them not contributing to the project and you will lose one of the benefits of web 2.0 – democratisation of the means of publication.

So why might someone not have this capability ? It could be economic (they can't afford to upgrade), it could be they are on a locked platform (they have an machine build supplied by the IT department that they can't upgrade) or they could just be unlucky and have a rouge machine which does not want to play web 2.0 (I am sure they exist!!). Whatever it is you need to make sure that everyone in the team can access the software.

Make sure that everyone in your teams can use the tools you want them to use

Many web 2.0 tools assume quite a high level of "web savvy-ness" before you can utilise all of the "cool" and "useful" features. If you assume that just because you have a passion for these new collaborative ways of working that everyone in the team will have the same approach – you will be disappointed.

Some will need one to one coaching to help them to understand the benefits that the new technologies can bring to them and the team as a whole. Again without this you have not opened up the means of publication. You should also take into account the pride of the people who are being engaged in your teams, many will have worked in other ways for many years and will not admit that they do not understand this new way of working. Therefore I would recommend that you always budget an amount of time for face to face training, which might seem a bit backwards for a tool to enable distributed collaboration, but my experience is that this can pay dividends in the wholesale adoption of web 2.0 tools.

Composite Applications in a Day – Possible ?

Having spent the last 5+ years talking about Composite Application I wondered what I had committed to when I suggested to SAP that CompriseIT could show people how SAP CE could be used to create a Composite Application in 1 day.

Could we really get 6-12 people from different organisations together and create working Co-Apps and have them leave understanding how we had done it ? We figured it must be possible, we had been working with CE for over 2 years and knew its capabilities inside out.

At the start of the first session we were full of apprehension, would the technology hold together ? would our guests identify a problem that was suitable ?

We launched to the day, identified our process (Customer Creation and Credit Check) and whilst I launch in to the theory of Co-Apps and SOA, our development team (of 2 people) started to build Web Services, wrap Enterprise Services, Build the User Interfaces and model and deploy the business process.

Shortly after lunch we had the first screens ready and demo'd to the attendees, modifications were made and the UI elements wired up to the process and it was time for playback number 2. With the process confirmed we could add the roles to each of the steps and throw in a Process dashboard and we were ready for the final playback...phew we had done it, a working composite in less than a day...

Since this session we have moved on to create more and more complex applications in our "Composite in a Day" sessions. These have covered :-

• Customers Booking Marketing Events
  
• Suppliers Requesting Non Conformance from Specification
  
• Requests for Import Licences
  
• Enquiry to Quote Process
  

Each of these Composites has interacted with at least one backend system , created custom Web Services, had at least 5+ user interfaces and 5+ process steps.

In addition the models created in these sessions could be used to evolve the application into a production ready application....so no mock-ups.

So what to be take from this experience ?

1. Model Driven Development Does Work
   
2. Business People really really like the flexibility that these tools bring
   
3. Some IT people don't like the flexibility they bring
   
4. These tools challenge traditional methods for development...you have to use Agile methods to really benefit from them
   
5. To master the tools inside SAP CE needs a multi-skilled team and time
   

Anyway, we are all very pleased with the output and our next challenge is to create a Co-App in 30mins...

 

 

Complexity vs Lack of Experience / Expertise – will it kill SOA ?

I have come across many people who talk about IT systems becoming too complex with too many moving parts. I believe that this is usually an excuse for lack of Experience / Expertise.

Think about the first time you drove a car...did it seem simple or complex ? Obviously it was complex, but once you gained experience it became easier and now you can do it without really thinking about it (assuming you have a driving licence!).

It is the same with IT, each time you have to install a new component it is going to seem complex and for sure you don’t want to install components just for the sake of it (This is why you need an architecture)...but don’t expect it to be easy the first time you do it.

This “complexity” debate reaches fever pitch with respect to SOA in many organisations as the number of systems/concepts/standards that need to be adopted becomes very high. For many the learning curve involved is just too steep to cope with at the same time as “doing the day job”. I believe this is a real inhibitor to the mass adoption of SOA - and may even kill many DIY SOA projects...

And You Thought Galaxy was Chocolate Bar...but it is a new BPM Tool from SAP

Just had a session at TechEd with the SAP guy who is heading up the development of the GALAXY Process tool that was announced yesterday at TechEd and it was a very interesting and frank session.

Thanks to Marilyn Pratt for sorting it out at the BPX club house.

Things I thought I heard (although I might be wrong) :-

1) Galaxy has a long term roadmap to become a process abstraction layer for SAP – you change the process model and the deployed system changes…cool
2) Initially the focus is "Edge" type Composition for processes outside the core SAP processes, the core maybe exposed later
3) BPMN as a model language – so that both business and IT can understand
4) Tool uses Eclipse so that developers and BPX, work together on the same model – no throwing the model over the wall
5) CAF Guided Procedures will be replaced – but can be used today – Galaxy is still some way off (12 – 18 months)
6) ccBPM will be replaced eventually once the process engine has been proved, but investment in BPEL models will be protected
7) The tool is about modelling and operation of processes. There is still a space for Enterprise modelling tools which model conceptual processes / optimise processes and include other perspectives.
8) Usage of the new rules engine (Yasu) will be key to reducing complexity
9) Many lessons have been learned from tools like CAF and ccBPM, easy usage is key

I think we can expect big things……

One size governance kills SOA Innovation

I have found that it is a great desire of people within IT to try to find a one size fits all approach to innovation management. Unfortunately, as you have to play to the highest common denominator this can mean that innovation gets lots in a mountain of governance paperwork.

Luckily, with the advent of standards enabled enterprise SOA it is possible to keep control AND encourage fast innovation. This is possible by keeping tight control of the service producers (backends) so you know that the atomic business logic is sound and having governance over the various tools used to combine the services into Composite Applications so you know that the final application will fit into your infrastructure.

Once you have this in place you can start to allow projects to use the tools with the appropriate level of governance for the project, not in terms of the budget but in terms of the new service producers and new tools that it uses. If it creates no backend services and uses known tools it should require less governance than a project that delivers a large number of new services and uses a new composition environment.

Let me use yet another house analogy : Think of this in the same way you govern changes to your house. A quick paint job requires little planning and/or control, a major kitchen refit does not require external control but needs carefully planning and budget control, the extension you put on the front needs formal planning consent and if you knock the house down to build 3 smaller houses you might have to go to a planning committee to check all the infrastructure can cope.

Taking these concepts to enterprise SOA means we can relax the controls of some of the projects that are redecorating the existing landscape with composites that open up the system or automate collaboration. We can do this because the atomic backend services ensure that we still update the critical business objects correctly.

So in an enterprise SOA world one size does not fit all.

The Long Tail of Applications

I have just been reading The Long Tail by Chris Anderson and one phrase in the book – Beneath Economic Viability – made me think about how current Enterprise Software requirement, design and development methods work against innovation – which is usually found somewhere in the long tail.

All the methods that I have used for requirements analysis work towards taking out differences in a process and trying to create a logical definition of a process that is modelled once and applied to the mass market.

We have all seen the impact of this on the acceptance of Enterprise Software. Some times we end up with a homogenised, bland solution that doesn’t quite fit everyone but does the job. Over time people work round the system running their “unique” processes in Shadow IT on spreadsheets etc. If we are really unlucky we get a solution that fits one set of users really well (usually those who were most vocal in the design process) and is a mismatch for those rolled in later who get no budget for changes.

Taking a lead from Chris Anderson we need 3 things to make sure that the long tail can be exploited :-

1) Democratise Production – We need to make sure that the tools to create new applications are widely available and easy to consume. YouTube is successful because ANYONE can create a movie now.
2) Democratise Distribution – Once you have created your application it needs to be easy to get it into the market place. This is what Amazon does to make 100,000’s of books available – some of which aren’t printed until you order them.
3) Connect Supply and Demand – With all the content that is available it becomes important to have ways to filter and connected related Applications. This is how iTunes drives recommendations for music you may never have listened to by analysing the community of individuals that it believes are most like you.

With the above in place it is possible to start to move the Line of Economic Viability so that the number of users for an application might only be small but the value it creates for them (and ultimately the organisation) can be large.

The good news is that many of the patterns we see in the commercial world are moving into the software world and the shoots of each of these traits is beginning to be seen…..if you look hard enough.

4 Killer Questions a CIO should ask his people…

1) Do you understand the Organisations Goals and how the IT strategy / Target Architecture helps to enable these ?

2) Do you believe that the IT strategy / Target Architecture will help to enable the Organisations Goals ?

3) Please explain how your activities are helping to achieve the IT strategy / Target Architecture ?

4) What skills do you have to help me achieve the IT strategy / Target Architecture ?

The answers to these 4 questions will help to inform your Communication and Change Management plan - the importance of which is discussed in this interesting blog by Sam Lowe - I will be trying to get along to see him at the Enterprise Architect Open Group Conference in Paris

Governance is NOT the answer

I have just had a major operation on my neck and it now looks like the picture below.


Before the operation I had been having discussion with many people over a number of months about the importance of governance in achieving the benefits of Enterprise SOA.......following the operation I think many people (most of whom sell some kind of Governance Consulting Service) have latched on to Governance not because it is the answer but because it is the easiest thing to consult in without actually having to deliver any working systems (a bit cynical you may think!) – which god forbid might actually solve some real problems and (wait for it) ADD SOME VALUE.

The reasons for this conclusion stems from the drug induced high I was on just after the operation when it occurred to me that I had not just survived the biggest operation of my life because someone "governed" it well (sure it was important that the right people were there and that they had the right tools) – I survived because I had EXPERTS working on me who had TRAINED for YEARS. If you read my blog on SDN about the lack of “real” IT professionals you will start to see what I think is the biggest problem with making SOA work……it is a lack of IT professionals !!!

It is these REAL IT Professionals who have experience, passion and vision that will be able to breath life into your new Enterprise SOA solutions. Nothing of any value EVER happens ANYWHERE if the group of people trying to achieve it don't have passion and vision (experience usually helps but is not a necessity – or we would never achieve anything new). Look at Iraq – the place has about as much Governance as you could throw at a place......but until you have a shared vision of the Target then it will be like nailing jelly to the wall….my advice to the Coalition is spend more time getting the Target vision sorted (it worked in Northern Ireland).

Anyway here is the KILLER question for those of you out there is CIO land…

WHEN YOU LOOK AT YOUR CURRENT TEAM AND YOUR CURRENT “PARTNERS” HOW MANY OF THEM HAVE THE EXPERIENCE, PASSION AND VISION YOU NEED TO ADD VALUE ?

I think you know the answer already :-)

You should promote the ones that do.....or you could commission yet another SOA Governance Study, Define a Charter for your SOA Competency Centre or Implement a Services Repository no-one will ever use.

Enterprise SOA will be achieved through expertise, passion and shared vision.

p.s If you do have a team who has Experience, Passion and Vision – can I have a job ☺

BETA Version or BETTA (BETTER) Version

This is the definition of a BETA version from Wikipedia

"A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black-box testing."

However thanks to the shop assistant (let's call him Shopii) at the Game Station where I just purchased my Nintendo Wii (for the kids...if you haven't played one you REALLY need to....) I think I have hit upon a better definition.

This is how the conversation went....

Mii - "Do you know what I need to do to get my Wii on-line"

Shopii - "Great news - it is all built in - if you have wireless at home then you are up and running"

Mii - "Cool - this Wii just gets better and better - I had assumed that would need to buy another box"

Shopii - "One word of warning the Browser is a BETA version - which means that it is gonna get BETTA !!!"

Mii - "Cool Dude - Bye (actually I didn't say this bit as I was laughing too much)"

Now I think this is a MUCH better definition of BETA....we are releasing this software to you and it is going to get BETTA...perhaps this is what Microsoft have been doing all the time....we thought BETA meant almost finished....but they meant we need to make it better :-)

Roll on BETTA software....Thanks Shopii

SOA Toddler Syndrome

Been a while since I blogged…life has been busy at work and home.

Anyway both of these have inspired another blog entry on the topic of sharing things.

My children are now 4 and 7 and as you can imagine they argue a lot about sharing toys (actually anything!), and this made me reflect to some of my work experiences trying to get organisations to put in place the required Organisation and Governance structures to encourage people to share IT assets which is at the core of the payback of any SOA/Platform IT strategy.

However you can’t make people share things as I know to my cost with my two children. However depending upon the maturity of the children I have different strategies to encourage sharing.

When they were less than 4 the strategies included :-

Bribery : Offer them some sweets / TV if they share with others
Distraction : Move their attention to something else so the other toy can be used by another child
Time-Out : Remove access to the toy for a short period of time

Now they are over 4 these strategies apply but we can also start to add more subtle strategies like :-

Free Toys : Explaining that if they share their toys they will get access to others toys free of charge
Interesting Games : Explain that if they share more children will want to play more interesting games with them

I am sure I could go on, but the point of this blog is that my very recent experience is that all of these strategies can be applied to change management strategies regarding SOA. However if you have a very immature client the “over 4” strategies may fail as they have not yet learned that simple sharing can bring benefits…before they move to more complex sharing and swapping.

An Ounce of Action is Worth a Ton of Theory

At the end of a very nice Chinese meal earlier this week my fortune cookie informed me that “An Ounce of Action is Worth a Ton of Theory”. I was dining with a friend who works for a large Enterprise IT Consultancy and we had been discussing why the practical up take of SOA appeared to be falling behind the massive amount of theory that was being created on the topic…….

I think the following are contributing to the problem :-

Issue 1 :

Some Enterprise Architects are trying to define all of the solutions to all the problems (lots of Theory) without actually putting this in to practice. If I talk to another EA who tells me all about their fantastic SOA, but then goes on to tell me their organisations is yet to deploy (or even model) as single widely used and available service or service based solution…..I think I will go mad.

Issue 2 :

The Enterprise Architects in most companies are doing a pretty poor job of explaining to the business what they can achieve with SOA, what does a business person do with flexibility and agility ? In most cases SOA does not provide ultimate flexibility and agility which means that the business departments who do think of something to do with SOA are often met with the Little Britain phase “COMPUTER SAYS NO”.

So we have a situation where not enough practical experience is being created within the IT department and a business who want innovation and change but don’t have any really good examples or patterns to follow….this all leads to too much theory and not enough action.

One simple chart that I use to explain what could be done with SOA is shown below.



I have translated the EA words of Flexibility and Agility into the simple to understand questions of :-

a) Do you want to create or automate a process and if so how complex is that process (and do you understand it !!!) ?
b) How complex (or pretty) does the user interface need to be ?

By plotting the answers to these questions on the grid we start to get an idea of how simple or hard the process of enabling this for the business is going to be.

As with all things (and SOA is no different) it is best to start small and grow as you gain experience and the great thing with SOA is that most of the skills you learn doing the simple stuff form part of the complex stuff as well. You might choose (and probably will) to use different technologies to enable each of these quadrants, I think this is OK as long as you keep a lid on too much technology proliferation. Each time you actually do something in the real world you will learn what works and does not for you – oh and you might actually add some value to the business ☺

AN OUNCE OF ACTION IS WORTH A TON OF THEORY !!

Flat Packed Applications - aka Composite Apps

I think we all accept that in addition to innovation and flexibility, reuse is a key cornerstone of the business case behind SOA. It is this reuse that means that the same logic is not re-written time and time again enabling organisations to focus on developing innovative new stuff to kill the competition with.

The problem is that getting people to reuse is hard and the key reason behind this is that to reuse something you have to understand it and to understand it you have to take the time to go through a learning curve (you also have to believe that the object is worth reusing).

Now thinking about most of the IT professionals you know in the world who create applications (me included), most of them love to create new stuff. At its heart IT is a creative pursuit – IT professionals are trained to solve problems in new and innovate ways !!!. So some change management is required to enable this change……

So let’s see how they fixed this in the world of furniture making (please stick with me) and see if we can apply these concepts to our own world of IT applications.

50 years ago if you wanted a new piece of furniture you had 2 choices, you either commissioned a bespoke piece (very expensive, but exactly what you wanted) or you purchased from a furniture maker (still expensive and sort of what you wanted). Then Flat Packed Modular furniture was invented….(by Mr Ikea ?). This totally changed the furniture market, it opened it up to people who had not bought new furniture before, it created volumes that enabled manufacturers to cut the costs of furniture AND importantly it did not put the (good) furniture makers out of business, because sometimes you still want that bespoke piece of furniture (to impress your friends or fit into that funny space).

Reflecting this example into the IT world, the bespoke furniture represents bespoke software, the furniture makers are the packaged application vendors and the flat packed furniture makers are SOA composite application platforms.

So how do flat packed furniture makers convince me to buy their furniture…..

Firstly they provide glossy brochures (or websites) that show me (and my wife) what could be achieved with their furniture range…..they don’t show me my lounge or kitchen (or even real kitchens), just examples that catch my interested in purchasing some of their components to put in my own lounge/kitchen.

Secondly (and this step is optional depending of how much I am spending - so key in the software world) they have shops where I can go and touch and feel these pretend rooms to see/feel the quality of the furniture and get design advice from (hopefully) trained staff !!!

Thirdly they (sometimes) provide clear instructions in the flat pack as to how all the different parts fit together and how different components are connected together. Hopefully I get a nice overview picture, step by step instructions to create the final piece of furniture, a list of the tools I need and an estimate of the time required to assemble.

Now some people will never buy flat packed furniture and some people buy it and get someone else to put it together…but you can’t deny that it has had a dramatic impact on the cost of furniture by encouraging us to reuse.

So where are we in the world of SOA and composite applications today ? Well with a few notable exceptions (SAP being one…well I would say that), we are effectively being shown a bunch of screws, connectors and bits of MDF….no big picture, no showroom and definitely no detailed instruction manual.

If we did have these then I believe at least one of the inhibitors to reuse would be removed…..then all we need to do is crack governance, scalability and requirements capture……☺

PUA

SOA is old news, what you need to be talking about is PUA - Pragmatic Unified Architecture.

So what is PUA ?

PUA is all about selecting the most pragmatic architecture style to solve the problem in hand, challenging the silver bullet ideas that one super architecture can solve all the problems that it faces...this doesn't work in real life (not even in Life 2.0).

PUA considers:-

- How long will the solution be used ?
- Does it have any chance to be re-used ?
- How much will designing re-use cost ?
- What non-functional requirements exist (performance, scale, security) ?
- What other components does it need to interact with ?
- Will the process supported change during the life of the solution ?

The answers to these questions will drive you to different styles of architecture, including Monolythic, Components, Event Driven and SOA and I believe you shouldn't just assume SOA is the answer...without asking some of these questions.

Now the other approach is to start using terms like SOA 2.0 or Advanced SOA or second/third/fourth generation SOA to include the above concepts under the umbrella of SOA....but personally I think this is b*******ks, call a spade a spade.

One other reason why you will need a PUA and not just an SOA is all the stuff you already have is already built and most of it didn't know about SOA when it was built...

At the end of the day any good architecture has just one acid test....can you point to a part of the architecture and explain to the business how it helps them achieve their goals (or why you are busy replacing it becasue it doesn't).

Life 2.0 Launched

Have you noticed how adding 2.0 to the end of words suggests that this is a new improved version of the old thing...no more problems just all the benefits....Web 2.0, Enterprise 2.0, SOA 2.0 we even had ERP II a couple of years ago (before it was cooler to call it 2.0).

So I launch here on this blog the concept of Life 2.0 - like the old life only cooler.

In Life 2.0 things will work like they should (in no particular order).....

* Meetings would always have a point
* My children would listen to a word I said
* People would actually use video conferencing instead of dragging people half way round the world
* .....

And blog entries would be nice and short :o)

Don’t under-estimate the importance of the composition platform

Lots of the stuff I read about SOA talks about what a service should be, how it should be charged for and how it should be governed. These are all very important aspects but are for the birds without a decent platform that allows these to be combined into applications.

Following 3 days camping this was brought into sharp focus. The site we were staying on had all the “services” that I have at home. We had empty_bladder_into_sewer, heat_food, covered_sleeping and we had additional services such as get_sun_tan, get_ice_cream and get_wine.

However the composition platform (in this case me) just wasn’t able to invoke these services as easily as it could at home. Trying to get empty_bladder_into_sewer to work with covered_sleeping was very hard to achieve, especially when combined with get_wine :-)

My main point here is that just having all the services was not enough without a composition platform that was able to take account of the non-functional requirements and make them appear to work as one.

SO - Should you believe the hype

Service Orientation (SO) is taking over the world or that is what most of the software and service companies in the world would have you believe. In some circles it is being touted as the answer to all the problems the last big thing created.

So is they hype justified....in a word NO.

SO will not make IT projects any more likely to succeed that ones based on previous architectures, in fact some of the first project will create huge failures - as many people will not understand the rat holes they may be venturing down.

First let's look at some of the things that make an IT project a success and then see how SO will impact on these dimensions.

1) Projects must have a good business case, sponsorship and budget.
2) Projects must have good project governance and a realistic timeline.
3) Projects must have a solid technology base.
4) projects must have capability that understands the problem, the solution and the technology.

SO - Business Case
SO does not change the fundamentals of the business case. Financial returns will remain the same. Where SO might make a difference here is where the re-use factor kicks in. If you are able to re-use components then the cost side of the argument should go down and therefore the ROI will increase. This might move things from "too hard/expensive" to "why not". If your SO guys are not showing any on this type of benefit..get new ones. So the fundamentals don't change but the TCO should be lower.

SO - Project Governance

Again SO does not change the need for good plans and accurate status reporting. SO does create problems for the traditional models as if components re-use is included (which is should be) then the dependencies between workstreams and other organisational units increases. Also the amount of experience in estimating and delivering these projects is quite low. If your SO guys can't show you where they have managed this complexity before...get new ones. So projects could become more complex and harder to manage.

SO - Technology

Hmmmmm....now everyone is claiming to be SO now...and inter-op and standards are at the core of SOA...so you can't go wrong....but you can . Don't assume that standards will be the answer to your problems, standards have the be implemented and sometimes these differ. Don't get me wrong it will work in the end but you will have to work at it. Also each of these "new" products will need to be managed, will have its own upgrade cycle and capability requirement. You could just decide to take your technology from one vendor, but this could be a) expensive and b) limit your flexibility in the future. If your SO guys are telling you not to worry about it...then start worrying and get new ones. So technology has the potential to solve your problems and create them..tread carefully and get your vendors to put skin in the game..

SO - Capability

Overnight everyone in IT is suddenly a SO expert, everything they have been doing for the last 10 years was really SO but they just didn't call it that. This makes recruitment of Systems Integrators and people a minefield. If your SO guys can't show you where they have really done this before...get new ones. Capability will increase in this area but make sure you know what you are buying.


So SO might make things quicker, cheaper and more reliable but only if you apply some good old management to the problem.

How much architecture is enough ?

Design vs. Styling

I listened to a presentation by a car designer from Landrover who defined the difference between car design and car styling.

He defined car design as working from the ground up to make sure that all the "big bits" were in the right place...his premise was that if all of theses are in the right place then the car drives well and looks good.

He defined car styling as what you need to do to a car that has poor design, you have to add bolt on parts and features to make the user believe that it is well designed when it is not....

This made me think about the world of IT where much time is spent on "styling" and not enough time is spent on good "design". It is the role of architecture to try to change this balance.