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

pityingmushroomInternet and Web Development

Aug 7, 2012 (5 years and 5 months ago)

287 views

Beginners Guide To Improving An
Organisations WebSphere Capability


Rick Smith, WUG UK



Edinburgh Event

17
th

June 2004

WebSphere

User Group (UK)


Agenda


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
WAS & J2EE.


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
future.


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
-
skilling


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.


On
-
ramp costs need to be understood


it’s not just the sexy stuff


Factor in
-

re
-
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


Open
-
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


more
solid solution evolves.


OO is not a swear
-
word


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
-
setter


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
-
result


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;
anti
-
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)


Open
-
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
micro
-
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.