Beginners Guide To Improving An Organisations WebSphere Capability Rick Smith, WUG UK

1
Beginners Guide To Improving An Organisations
WebSphere CapabilityRick Smith, WUG UK

• Edinburgh Event
• 17th June 2004

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

3
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).

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

5
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, RD, 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 RD and Maintenance
• Obtain Executive sponsorship failing to maintain
  pace with technology costs more, unless you plan
  to never change its 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 its always a
  good idea to seek external advice help, but
  also listen to your people important to gain
  consensus, dont 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.

6
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 its 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
• Dont 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 its 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.

7
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 SIGs 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 dont
  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 dont 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 Glossaryetc
• Recognise fears of current experts when
  introducing new technology
• Your current heroes can see new technology as a
  threat, its natural try to work with involve
  them - if you need to integrate, you may depend
  on their support.

8
Developing your Capability (2)

• Establish induction process for internal
  external resources
• Those brought in dont know your architecture,
  they need a point of reference to get them up to
  speed quickly be open to alternative views, but
  dont 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.
• Dont 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.

9
Building your Architecture (1)

• Keep pace with technology, but dont 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.
• Dont re-invent wheel
• Whatever your think of, its 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
  reqs 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
• Lots 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.

10
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 reqs
  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.gs 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 dont 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.

11
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, theyll always treat helping
  you as a priority encourage your team to keep in
  touch with trainers contacts at conferences
  dont be afraid to approach them, they may be
  happy to visit your company present/help
  (sometimes it costs).
• Plan for support theres always an answer if
  youre 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 PMRs which traces, logs, etc not
  supplying could result in costly delays.

12
Working with IBM (2)

• Dont 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 dont
  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 ?

13
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.
• Dont 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 Ive seen
  time again.
• Capture share key learnings from crit-sits,
  major issues, etc
• Nobody likes post-event analysis documentation,
  but its the best time to capture key learnings
  prevent from repeating in someone elses 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.

14
Managing your project team (2)

• Use a defect management tool.
• Youll 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.
• Dont 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 reqs in-flight at meetings
  can prototype in meetings can test and fix in
  remote locations etc.

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