Welcome to the Conference !

Hello everyone,

I’d just like to start off by thanking the Open Group for organising this event, specifically
John Spencer, who kindly asked me to present to you all today, and Allen Brown, the
Chairman of the Open Group, who’s given Sun, and I, a very warm welcome today.

And I’d also like to thank you all for coming along to see me, I hope you enjoy the
presentation.

Introductions

So who am I ?

My name is Wayne Horkan, and I’m the Chief Technologist (CT) for the UK and Ireland at Sun
Microsystems.

I’ve been the UK & Ireland Chief Technologist for the last eighteen months, and I’ve been
at Sun for the last seven years, in total.

As CT I provide Technical Leadership to the entire UK and Ireland Sun organisation, with specific responsibilities for the senior customer facing Business and Technology Consultants in that organisation. A significant part of my role is spent engaging with our customers, and I sit on a number of our customers Technical Governance structures and boards – all of whom are responsible for generating and managing EAs.

Furthermore historically Sun and the Open Group have had an excellent relationship, with
Sun having been a founder member of the Open Group.

Contents

I’m going to cover the three major uses of EA at Sun Microsystems, including three case
studies from our customer engagements.

After that I’m going to discuss our “Seven Rules for Successful EA”, which were drawn
out from lessons learned from these and other engagements.

That’s going to be followed by a short Q&A; before I finish.

The 3 major uses of EA @ Sun Microsystems

If we look at the three major applications of EA at Sun Microsystems, they are:

1. Internally – EA used by Sun internally to manage it’s own IT estate
2. Externally – where Sun consultants have been involved with customer EA teams and
   EA initiatives
3. Both – Or rather EA practiced internally to better understand our external customers’ IT
   estates

EA used internally at Sun

EA was introduced into Sun Micro by our previous CIO – Bill Vass.

Before Bill came to Sun he worked in the Office of the Secretary of Defense, Office of the
CIO. In this capacity, Bill was director of three large sectors of the U.S. Department of
Defense’s IT infrastructure. and was very familiar with EA from the introduction of
DODAF.

His roles at the DOD included:

1. Director DOD where he was software manager for over 30 projects
2. CIO at the Pentagon in infrastructure
3. Networks operation Manager at the Security’s Division

Sun has an EA office which co-ordinates EA across Sun’s IT Operations (‘ITops’) – Bill
set this operation up about four years ago.

Our current CIO – Bob Worrall, having taken over from Bill about a year ago has the EA
office reporting directly to him.

Sun internal EA has delivered…

It has delivered 3 important pieces of work:

1. An EA of Sun’s IT Ecosystem – but an EA is not just a means in itself. By developing
   an EA we have been able to start work at EA Planning, and thus able to deliver even more
   definite business benefit.
2. Project Helios, which has been delivered into production, an online Runtime,
   Service/Asset Management System. This for me is “Asset Management evolved” – as it
   allows you to view at Runtime Business Services to Business Units, to Application
   Services, to Application, to Operations Team, to Infrastructure & Hardware, to Data
   Centre & Location and to Facilities Management. It is a cornerstone of our SOA adoption
   roadmap and will become an online management information system.
3. Project IBIS, stands for “Integrated Business Information Solution” and is a
   concentrated effort to reduce complexity across the Sun IT Estate. The IBIS project will be
   looking at consolidating circa 1,000 business applications, world-wide, into a single
   Oracle Financials runtime. We are achieving this strategy by replacing the atypical “80%”
   of all functionality with a single implementation of Oracle financials, combined with an
   SOA approach of encapsulation & aggregation for the remaining “20%” functionality.

In the UK we have a saying about Cobblers Shoes – the saying goes that cobblers shoes
are always in poor condition because the cobbler could at any point repair them – that’s
what he does of course. And I think a little of that happened at Sun.

Because were a technology firm, full to the brim with smart innovative technologists, it
was always supremely easy to construct applications, and even worse – easy to support
them well into production.

Thankfully Project IBIS is going to change that. We have spent the last 2 years auditing
all related and impacted business processes and applications across Sun and have
developed a plan & route into the future. Furthermore we have implemented a governance
structure which will minimize this happening again.

Obviously Project IBIS is a massive concern – affecting circa 40,00 staff worldwide, not
only producing efficiencies in the Supply chain, simplification of the Estate, but also
reduction of support required and the costs attributable to such a difficult to manage IT
estate.

So you can see we have a very live, well placed and well sponsored EA function within
Sun.

EA used externally for Sun Customers : Why do customers involve Sun in there EA Programmes

Next I’m going to talk about the use of EA externally with our Customers.

Sun gets involved with customers EA initiatives, and we are often asked to supply Senior
Technologists into customers EA governance structures to help with EA definition.

This happens for a number of reasons, including:

1. Vendor representations – customers want tier one vendors to act as IT / Technology
   industry representatives.
2. Decision ‘Backup’ – validation of opinions and techniques based upon experience of
   seeing it being done elsewhere.
3. Trust – the customer trusts Sun for impartial advice.
4. Reliance on core technical stock – if the customer has a large amount of Sun technology
   they might want representation from us in moving that forward.
5. Consultant specialist knowledge, experience or relationships – an ex-employee, for
   example, or someone involved in a previous implementation.

EA used externally for Sun Customers : Supporting customers EA teams helps Sun to…

As the Technology Leader for the UK and Ireland, I actively encourage these relationships
– as they:

1. Give Sun a chance to demonstrate value – outside of pure product.
2. Allow us a better understanding of the aims and challenge of our customer
3. De-risk implementations by giving us opportunity to contribute to the design and
   implementation of new systems as well as a long term and strategic view of the customer
   IT ecosystem.

Additionally it allows us to “up skill” our own staff in EA delivery.

EA used externally for Sun Customers : Three EA case studies…

I’d just like to talk briefly about some of the customers who we’ve worked with their EA teams.

I’m going to cover three case studies:

• firstly a large utility company – “When EA goes ‘Bad’”
• secondly a very large government department – an example of “EA and SOA”
• thirdly, another extremely large, government organisation – “EA Technical Governance” or “it’s about the people, stupid !”.

EA case study no. 1 : A large Utility company : When EA goes ‘Bad’

We got involved with the EA work at this customer around 3 years ago. It was extremely
interesting to see how EA was being used, how it had evolved and the issues that they had.

I call this “when EA goes bad” – because in my mind it was the best (or worst, given your
viewpoint,) example of “Ivory Tower Syndrome” – a problem when EA teams become
isolated, withdrawn and stop communicating.

Issues included:

1. EA was over “deliverable focused” and “data driven” – with a lack of a “big picture”
   view.
2. Not Inclusive – leading to severe “Ivory Tower Syndrome”.
3. Lack of clear objectives for the EA team to deliver against.
4. £80m spend on a single project cancelled – due to the EA Team.
5. No / lack of Senior Sponsorship / Visibility – Accountability

I personally conducted two reviews for them. Firstly, a review of the vendors to their 70m
pound outsourcing deal – where we subsequently had to redesign their proposed operating
structure so that it was based upon a cross cut of technology skills and vendor and
project inclusion.

Secondly a review of an ongoing project which had incorrectly been identified by the EA
team as a strategic component. Initially this was a combined workflow and customer
management system – including remote, wireless, handheld data collectors (for ‘pipe’
asset location).

The programme had been due to deliver £1 m in a year savings, initially costing £8M This
had very soon ballooned to £11M, then £40M, and finally £80M – including requiring an
estimated further £40M, so a total of £120M, to be delivered.
You may ask why a programme with a 120 year return on investment (ROI) would still be
being delivered.

Unfortunately the EA council, which had become very parochial due to a lack of new
members and lack of integration with the project members & architects had deemed parts
of the program to be fit to repurpose as an Enterprise Service Bus (ESB) – effectively they
said that the programme was delivering a Strategic corporate component.

This wasn’t the case as it was built as an “end-point system to end-point” system model
(commonly called Point to Point). A legacy approach to integration, one that, for apart
from very small systems, has been discounted. It’s extremely costly in terms of connecting
new systems and would not scale as an Enterprise corporate component – neither in terms
of ease of re-provisioning nor development nor Runtime reusability.

If the EA team had listened to the development team they would have known this – but
because of “Ivory Tower Syndrome” and the organisational hierarchy involved they were
not open to learning this particularly bad news. The EA team had become elitist, out of
step with the business, disconnected to the project teams, and had stopped communicating.

After reviewing the Programme it was shut down by the incumbent IT Director, with the
resultant loss of over 400 jobs. Obviously we were congratulated for saving the other
£40M – but I would have preferred for the original EA team to have not become so
inwardly focused, and to not have mistakenly championed a system which would have
never have been able to grow into the strategic corporate component that they had
imagined. We subsequently helped the customer to rebuild its EA function with a new,
inclusive Governance structure.

EA case study no. 2 : A large Government department : EA & SOA – the perfect marriage ?

We were asked to get involved with this customers EA board when they were reviewing
their SOA implementation and had asked Sun to develop their SOA Adoption Roadmap.

We found a legacy enterprise model which had not been updated for a number of years –
unfortunately it had been delivered by Business Analysts so it was very much a catalogue
of business processes. Very little was related to real world application / logical or
infrastructure / physical technical domains.

We found that to deliver a realistic SOA Adoption Roadmap – in terms of ability to be
implemented – we needed the beginnings of an Enterprise Architecture to provide a
contextual backdrop upon which to base our SOA Adoption plan.

So we started by rapidly developing a light weight yet inclusive EA Model which included
the major corporate components that were due to be involved in the SOA implementation.

EA case study no. 2 : A large Government department : EA + SOA = SOA Adoption Roadmaps

We were able to define the strategic roadmap (and roadmaps) for implementation of an
SOA across the organisation, once this was done. Furthermore, we could understand the
implications of what we were planning to do by their impact on the other corporate
components. This allowed us to model differing roadmaps, and judge them on a variety of
criteria.

The SOA Adoption Roadmaps could be compared and judged against:

1. Functionality delivered – i.e. what capabilities would be introduced at which point in
   the overall implementation plan.
2. Costs to implement – for each stage, or alternate stage, what the cost would be, as well
   as it’s relationship to previous and future stages.
3. Complexity of implementation – how difficult it would be for each stage, and some of
   the risks involved (large discreet stages, versus, small “phased” stages).
4. Non functional, but strategic and re-useable – the “cross the board” estate capabilities,
   such as the messaging sub-system (Enterprise Service Bus, or ESB, as it’s also known),
   non-functional items such as aggregated audit, which could be re-used outside of the SOA
   implementation.

EA case study no. 3 : A large Government organisation : “It’s about the people, stupid !”

This case study is about EA & Technical Governance – and I’ve called it “it’s about the
people, stupid!”. EA is really about the people – those helping to deliver it, those
influenced by it, and those who it delivers for. I feel that it is imperative to get the right
mix when building an EA function.

The organisation at the centre of this case study is the single largest employer in the UK,
with around 1M staff. It is a distributed organisation supporting the needs of all subjects
in the UK.

It is currently going through a massive change program – an ambitious plan to provide an
integrated stack of functionality across the organisation and it’s subsidiary organisations.
Comprised of a central message subsystem and five major Service Provider Regions. Sun
is involved in delivering the messaging subsystem, or rather G2G backbone (very similar
to a B2B system) which supports all data traffic.

I was asked to intervene in an issue with the prime vendor / supplier to the end customer –
one of the largest UK telecoms companies.

When I got on site I realised that the issue was one of technical governance model and
that although we had teams of application architects and teams of infrastructure / system
architects we did not have any Enterprise Architects. People who would get a contextual
view of what was being attempted, nor, as they weren’t any, our ability to map to the
customers EA team !

By insisting we had a team of EA’s led by one of Sun’s most experienced Enterprise
Architects we were able to move the project out of escalation and avoid severe financial
penalties, which would have been levied if communication had continued to fail between
our teams.

Enterprise Architecture and Innovation…

At Sun we see ourselves as a force for innovation – and the vanguard of disruptive
technologies.

So it shouldn’t be a surprise that we take EA principles and methods and shake them
around a bit … quite a bit.

At Sun in the UK and Ireland we are using EA in the pre-sales process, obviously where
possible and legally acceptable, to map customer accounts.

   …using EA to perform customer analysis

We also use EA techniques to help understand our customers better. Often our customers
are more than happy that we are so interested in them, and the successful evolution of their
IT / IS Estates.

We call these rapid, light weight, EA methods collectively as Sun LEAF (Light-weight
Enterprise Architecture Framework)

By mapping out our customers IT / IS Estates, and by relating Business Units, to
functional and non-function corporate components and the application architectures,
software stacks and physical architectures that under pin them we are able to learn an
unprecedented amount about our customers use of technology.

We can use the information to identify a number of items – such as which corporate
components consist of Sun Technology – and more importantly which ones don’t – and
thus are applicable for targeted sales. Which business units have systems we have no
visibility at all – and so we need to investigate more. What technologies connect together
and how easy it might be for us to displace them with the least amount of impact on the
customer estate.

The Sun LEAF programme is currently in its second pilot prior to roll-out. Some significant
success have already been made, which I can’t currently disclose at the moment.

In Summary – Enterprise Architecture ‘Best Practises’

That wraps up the overview of EA use at Sun Microsystems. However, I thought it would
be useful to look over the best practices we have identified and developed at Sun for EA.

I think it’s obvious that EA needs to rapidly speed up it’s time to delivery – without a large
drop in the quality of EA being delivered. Basically we, as Enterprise Architects, all need
to be smarter at our game. That’s why I welcome the focus on EA methods, tools and
standardisation that this conference, and the Open Group bring.

I’ve seen too many EA programs either fail to deliver against there original goals, get lost
in the detail without delivering the “big picture” / contextual view promised, and,
increasingly in the UK and Ireland, where the average time in role for a CIO in a top 200
company has slipped to 2 to 3 years maximum, fail to deliver in the timescales of the
original sponsor – only to lose sponsorship & support and be closed down without
delivering at all.

1. EA must relate to a definite deliverable goal or aim – otherwise it can become an in
   means in itself. Obvious examples include:
   • Reducing complexity – and the cost reductions and savings that obviously result
   • SOA Adoption Roadmaps – or EAI / Integration
   • Plan for the future of the technical Estate – fashionably called EA Planning.
2. Don’t labour it – keep “fast and light weight”. Unless you really need to – get quick
   demonstrable ‘wins’ onside to encourage buy in and acceptance. Think about the concept
   of “gearing” – delivering discrete pieces of the EA which can relate to actual business
   value which can then be used to justify the next stages proposed.
3. Inclusion – Involve people from the wider technology eco-system, both internally and
   externally – both vendor and project staff
4. Rotation – avoid “Ivory Tower Syndrome” by rotating staff in and out of the EA team
5. Get the right Technical Governance skills base mix (NB Use the whiteboard to
   demonstrate – EA Technical skill domains spider diagrams developed by Sun)
6. Must get the right level of sponsorship – EA functions straight into the CIO office.
7. Keep aligned to the Business Strategy Board – EA is about the Technical Strategy for a
   company, and it must relate to the Business Strategy of that company – or will end up
   delivering something that the business can not adopt.

Where can you get EA help at Sun Microsystems ? Try over here…

So where can you get help from Sun re: Enterprise Architecture.

If you have a Sun account team, and I know some of you do, then use that account team to
identify local experts – reference this event, my presentation and me too.

Alternately you are very welcome to get in touch with me, and I’ll either help identify the
best person to help you in the circumstance, or even work with you directly.

Q&A;

That concludes my presentation on Enterprise Architecture @ Sun Microsystems – I very
much hope that it’s been enjoyable and educative.

My contact details are on the slide behind me – if you’d like to get in touch I’d be very
happy to hear from you.

We just have time for a short question and answer session – so any questions ?

Thank you very much & enjoy the rest of the Conference !

Thanks a lot for all your questions, and thank you very much again for coming along to
see me today.

Just like to say “all the best” and I hope you all enjoy the rest of the conference.

PDF with speakers notes

PDF without speakers notes