WebSphere BI User Group – March 17th at IBM Bedfont Lakes

pityingmushroomInternet και Εφαρμογές Web

7 Αυγ 2012 (πριν από 5 χρόνια και 11 μήνες)

305 εμφανίσεις

Beginners Guide To Improving An
Organisations WebSphere Capability

Rick Smith, WUG UK

Edinburgh Event


June 2004


User Group (UK)


A brief intro to me.

Presentation objectives & disclaimers.

Organising for WebSphere.

Developing your WebSphere capability.

Working with IBM.

Managing your project & team.

Any Questions.

Close in 30 minutes.

A brief intro to me

Large supermarket retailer for past 13 years, one of the
biggest investors in IBM within EMEA.

Large bank before that

variety of IT roles in 20 years.

Oct 2000

May 2002: Java Services Manager, establish

May 2002

May 2003: Development Services Manager,
broaden to include EAI.

May 2003

Dec 2003: Integration Services Manager,
focus on Integration, incl. J2EE.

Dec 2003

?: Enterprise Architect

oversee WebSphere,
J2EE & EAI, seat on Architecture Review Board, plan for

More in Event Handout bio(s).

Presentation Objectives & Disclaimers

You leave with at least one useful nugget that you feel
inspired to follow up.

You will share with WUG UK one useful nugget in the
future that others may be inspired by.

Basis for a future Birds of a Feather (BoF) session.

I only have 45 mins.

My current situation.

Intended audience.

There are no absolute right or wrongs.

There are no magic pills, silver bullets or original thoughts
& definitely no substitute for ‘homework’ & hard work.

Organising for WebSphere (1)

Build Enterprise Architecture into IT Strategy

Executive sponsorship; Defined, documented & published; Architecture Review
Board sign
off within programme & change management; reward compliance.

Community of practice with centre of competence

consistency is key

Technical Specialists, R&D, standards & best practices managed centrally to
support dedicated project resource; WebSphere can be complex & overlap with
other solutions

it can easily get out of hand if not managed.

Budget for R&D and Maintenance

Obtain Executive sponsorship; failing to maintain pace with technology costs more,
unless you plan to never change; it’s better to plan for adoption, than to adopt out
of necessity in time of crisis.

Adopt a customised methodology framework

Combine elements of methodologies to suit your organisations needs, e.g. XP,
RUP; it’s always a good idea to seek external advice & help, but also listen to your
people; important to gain consensus, don’t impose without majority backing.

Communicate, communicate, communicate

Construct a simple message & build on it; pictures speak louder than words; repeat
yourself without shame; be patient & try not to impart wisdom

not everyone gets
it first time around.

Organising for WebSphere (2)

External Audit of your architecture, skills & processes

Yes it costs, but could lead to a clean bill of health or a saving; see what you can
learn from those trying to get a foot in the door, e.g. development, test, change, etc.

Ensure your core legacy data & systems defined, before it’s too late

Data architecture team; template for defining (UML?); unless you have an asset
analyser tool, analysis of old systems & databases without expertise can be very
costly in terms of time/resource and will likely result in failure to deliver on time.

Be careful when selecting candidates for re

You need

aptitude for complexity & problem solving; open
minded, using
multiple inputs; adaptable; self
sufficient & self
motivated; proactive & interested;
team player; approachable; reasonable communicator; not averse to documentation.

Sensible approach to developer workstations

Don’t ‘lock down’ so much they cannot do their job effectively, but instead make
clear org policy & consequence of abuse; use automated software distribution to
manage patches & new releases; trial changes before roll
out & change manage.

Procurement guidelines compatible with Enterprise Architecture

Otherwise contracts could be signed tying you in to incompatible solutions.

ramp costs need to be understood

it’s not just the sexy stuff

Factor in

skilling; expert help; hardware for tools & servers; support & admin
impact; supporting tools, e.g modelling, monitoring, testing, etc.

Developing your Capability (1)

Encourage & support learning culture

reward champions

Internet access; knowledge base on intranet (e.g. Twiki); subscriptions across team;
personal development plans include technical skills; forums & blogs;
internal/external SIG’s; User Groups.

Ensure you have coverage of all key skills

Have one master per key technology/skill, preferably two, in a resource pool where
everyone trained to know all key skills within role; don’t become too dependent on
one individual, good people at affordable rates hard to find.

Education, education, education

Find suitable windows in IT programme for team training; agree personal
development time with objectives; don’t set unrealistic expectations for skills
adoption; sensible use of conferences and events; identify courses, tutorials,
webcasts & books that maybe useful ahead of time (some free online).

Documentation is critical, but keep it manageable & useful

Architecture Definition, incl. UML and diagrams; Architecture Decisions, incl.
portfolio of approved technologies, tools and patterns; Capability Definition, incl.
purpose, scope, principles, skills and roles; Naming standards; Best practices

why, what, when, how; Known Issues; Enterprise artefacts; Glossary;etc

Recognise fears of current experts when introducing new technology

Your current ‘heroes’ can see new technology as a threat, it’s natural; try to work
with & involve them

if you need to integrate, you may depend on their support.

Developing your Capability (2)

Establish induction process for internal & external resources

Those brought in don’t know your architecture, they need a point of reference to
get them up to speed quickly; be open to alternative views, but don’t allow ‘quick
win’ sacrifices unless you fully understand impact & risk; use Trails on intranet.

Provide templates & workshops for project teams & stakeholders

E.g. Requirements, including architecture & UML; E.g. risk management, seek
help of professionals in your business, e.g. Business Controls; examples on web.

Use Test First approach

source frameworks that enable repeatable unit tests to be coded, before the
application code, e.g.. JUnit, Mock Objects, HttpUnit, DBUnit, etc; enable tests to
be included in auto
build process, e.g. using ANT, where build fails if test fails.

Don’t perfect design before coding, incrementally build & refactor

Have a good set of requirements & user stories (use cases), sound analysis, then
design as much as you need to, code some, learn something, refactor, repeat

solid solution evolves.

OO is not a swear

it is still relevant

Right responsibility in right object (class); loose coupling; encapsulation; etc

Regular team
level reviews of design, code, tests, documentation

Helps to share skills; enables decisions to be captured for future support; drives out
architecture decisions & exceptions to be ratified; buy expert help first few times.

Building your Architecture (1)

Keep pace with technology, but don’t be an industry pace

Most new technologies require 12
18 months to mature before reliable &
supportable; if business benefit outweighs risk, then consider production use.

Don’t re
invent wheel

Whatever your think of, it’s already been done; avoid ‘island mentality’.

Plan for future

growth, extensibility, compatibility & upgrading

Building only for today potentially means higher costs further down the line; avoid
future incompatibility during design; agree upgrade plan before you start
deploying; always ensure projects understand cost of growth, e.g. storage,
bandwidth, certificates, etc; always worth having some slack built in.

Seek reusable Enterprise components & services, but remember reuse
is a poor objective but a good end

Always keep to current requirements & build to be extensible

try not to second
guess future req’s; run intermittent ‘common code’ initiatives to identify, harvest &
prepare reusable classes, etc; 2
3 instances is a good indicator of reuse potential.

Patterns for success

Lot’s of patterns available that have evolved from success stories & painful lessons

use them properly & massively reduce risk of architecture & solutions failing; not
only for design & code, also for config management, testing, organisations, etc;
patterns also available; good sources of patterns

GoF, Fowler, J2EE, IBM,
etc; IBM Patterns for Business Integration & other P4EB evolving

look good.

Building your Architecture (2)

source/freeware can be a life
saver & not as risky as you think

Usual concerns re support unjustified

usually better than software provider; can
add new req’s quicker than vendors; good kudos for you & your better developers
to be involved; useful for new technology/skills on
ramp if awaiting licenses; the
good stuff can become mainstream in vendor solutions; e.g’s Eclipse, ANT, JUnit,
CVS, Mock Objects, JDOM, MySQL Hibernate, AOP, Naked Objects, JCOM,
Apache Xerces, Jakarta ORO, Java Service Wrapper, Mozilla, Spring, etc.

If you can, automate as much as possible

build, ops admin, test, etc

Human error single biggest cause of support issues & downtime, so give the
humans a helping hand; ANT scripting tool should be mandatory (although other
options do exist)

repeatable build that run unit tests, generates JavaDoc, updates
repository, etc; Tivoli great tool for Ops Automation & infrastructure monitoring

restarting servers, apps & services after downtime, generating alerts, etc.

Perform vendor trials to coincide with a need you have

Examples are performance testing or monitoring; put onus on vendor to prove to
you in real situation that their tool is easy to adopt & works, e.g. 3 month trial;
don’t be totally dependent on outcome; if good, real evidence for business case.

Good idea to wrapper downloaded code to standardise

If using something like Log4J (open
source java logging component), then wrapper
to provide a standard interface, hiding complexity from developers & enable you to
replace at later date without need to change all your applications.

Working with IBM (1)

Ensure your account team is working for you

Every success I have achieved with WebSphere has my IBM account team to thank
in one way or another; pre
sales good at giving post
sales support; IBM Client IT
Architect and Deployment Managers essential if you can justify/afford them; good
sales team very helpful organising right speakers & experts when required.

Network, network, network (not the TCP/IP kind)

IBM is a big org, but there are some real heroes

some are here today; always keep
in touch with good contacts; always seek to give & take

if you can help them,
they’ll always treat helping you as a priority; encourage your team to keep in touch
with trainers & contacts at conferences; don’t be afraid to approach them, they may
be happy to visit your company & present/help (sometimes it costs).

Plan for support

there’s always an answer if you’re prepared & know
who & how to ask for help

Ask IBM to help determine possible issues & how to prepare for support

WebSphere Software Services team particularly helpful, but in demand & cost, so
also see Redbooks, DeveloperWorks, User Group downloads, etc; ensure standard
process for exception handling & logging; find out beforehand what will IBM
typically require for PMR’s

which traces, logs, etc

not supplying could result in
costly delays.

Working with IBM (2)

Don’t always assume software does what it says on tin.

IBM are a big company & in my experience endeavour to provide what they sell
you, but there are so many variables in your architecture & so many people
involved in IBM, not everything goes right straight away; moral of story is don’t
bet your mortgage on a new release being ready to deliver all the goodies in
production on day1; do get involved early to get ahead of game and learn.

Use reference accounts as a yardstick

IBM normally can arrange visits to reference accounts to compare experiences; not
normally possible with competitors though

Lots of resources & events provided by IBM, use them

Developerworks; Research sites; case studies; trial software; redbooks; tutorials;
technical conferences; sales events; user groups

Managing your project & team (1)

New skills or architecture usually biggest risk to project

Ensure you address these risks early & prove a new architecture before you commit
to deliver on it within certain timescales

there are so many things that can go
wrong & not all of them are easy to solve; having too high expectations on your
team to adopt new skills can also result in failure to meet deadlines.

Don’t treat performance as THE risk in a project, manage all your risks

Often performance seen as a risk by default & clean solution designs modified to
mitigate before risk is even understood; better to start with good design practice but
have some ideas of how it can be changed to cater for performance issues

For every minute saved cutting corners, add 2+ minutes to post
implementation in support

Not a scientific measure, but one that I’ve seen time & again.

Capture & share key learnings from crit
sit’s, major issues, etc

Nobody likes post
event analysis & documentation, but it’s the best time to capture
key learnings & prevent from repeating in someone else’s project (or yours!)

Use sound team
level config management & version control practices

NO local copies of code; continuous integration, one co
ordinator; agreed
branching practices coordinated with team leader; CVS good tool; etc.

Managing your project & team (2)

Use a defect management tool.

You’ll pay price otherwise; use to schedule, prioritise, provide audit trail, etc, for
defects & change in requirements; ClearQuest good, but there are free tools.

Separation of concerns within roles is good practice

As long as you have technical team
leader focusing on project requirements and
overall solution design.

Locate your project resources as close together as possible

There are multi
site tools and methodologies, but much better to reduce
miscommunication and possible ‘them and us’.

Don’t over do Gantt charts and do consider using timeboxes

Gantt is good tool to estimate project timescales, resources, etc, but not good for
managing tasks in iterative projects; timeboxes negotiated as contract
between team
leader and developer better tool for planning and tracking during
design, build, etc; high
level Gantt for communicating progress.

Get some laptops for your team

Good for capturing req’s in
flight at meetings; can prototype in meetings; can test
and fix in remote locations; etc.

Any Questions?

Thank you for your time, I hope you
think it was well spent.

Let me know if you want a more detailed write up
with reference list including links & publications.