Uklug 2011 administrator development synergyPresentation Transcript
UK Lotus User Group 2011 Presented By: Steve McDonagh & Frank Docherty Admin-Dev Synergy Fact or Fiction?
Some useless facts about Frank
Worked with Notes & Domino for 16 years (Since Release 3, in case you wondered)
Has been a help desk guy, desktop support engineer, server support engineer, systems administrator, support team leader, IT consultant, software asset manager and project manager
I am currently a Senior Notes & Domino / BES / Sametime administrator within a company that operates at a global level, supporting operations within the UK, Europe, Asia & Americas regions
I live very close to the Tunnocks factory in Uddingston. Too close perhaps ...
Some useless facts about Steve
Has been a Mathematician , Registered Nurse, Licensed Herpetologist, Rock-star, Cartoonist and manufacturer of the Rob Novak levelling “Pink Stuff”
Worked with Notes & Domino for 126 years and 3 months (or 18 years if you are not a dog)
I am currently the “Global Collaboration Manager” for a Sino / American Corporation with a deployment of Domino / Quickr / Sametime / Traveler and BES servers
I live very very close to Bushmills Distillery in Northern Ireland
Within any Development / Administration environment far too often the two strands are separate and never the twain shall meet. (And if they do there will be tears before bed.) Much of what we will look at today many of you will consider utopian, wishy washy stuff that does not work in the “real world”, but here is a telling graph
However, we put this before you as a template not of what should be, but what could be … if you were to let it happen.
Architecture & Design
Quality & Defect Management
Operations & Support
Requirements All application development projects start with the gathering of requirements. To some DEVs the ADMIN side of this is more often than not an afterthought. We suggest that both sides need to be involved at this early stage, but mostly it will be a development collection process which should be encouraged to collect not only from the User groups but from the Admin team
Project Management Regular meetings of a project team made up of Devs and Admins will lead to an application that starts of with an element of balance between the Admin and Dev sections of the team. The early assignment of roles and responsibilities within the project will lead to a more cohesive project team. ( You may need a box for some admins to stand on ...)
Architecture Once the requirements are close to being agreed, the admin members of the team start to come into play. Choosing the appropriate architecture for your application is key, have an admin that understands the detail of the platform(s) and the nature of the project. That combined with a dev that understands the complexities of the data, code and the nature of the platform will definitely make the project run smoothly and lead to better software!
Design Even with a good architecture it is still possible to have a bad design. Many applications are either over-designed or under-designed. The two basic principles here are the old PHP axiom of “KISS - Keep It Simple Stupid” and that of “Information Hiding”. UML is very useful for this particularly on large or projects that bring in different platforms, data sources and coding paradigms. Skill up your Devs AND Admins so they know the principals of UML and can understand what the other person on the team is proposing and respond accordingly to the challenges uncovered in a way that can be understood by everyone. A good collaborative tool is useful here ;-)
Cutting Code This is what Devs do well and do best. However sometimes their levels of enthusiasm can get the better of everyone! Talking about the back end processes with an Admin team member before that “ kill-the-server-run-every-5-minutes-agent” is created can push the code in a different more efficient direction. (And save you from the wrath of Angry Admins)
Review Regular reviews of the project by the whole team are essential to the success of the project. Regular reviews let the Devs know that the architecture is following the code and vice a versa for Admins. Regular reviews keep everyone informed (and happy, for the most part) For an even more harmonious project review meeting experience TM , why not have regular project reviews over a cuppa and biccie?
Testing Get your Admin team involved with planning and execution of actual testing!!!! It is their servers you will be running this on, they are used to the intricacies of performance and they WILL HELP! Use a framework, test not only the code does what it says on the tin, but does it in an efficient and timely manner which does not cause the whole system to suffer.
Configuration Management Configuration management involves knowing the state of all artefacts that make up your system or project, managing the state of those artefacts, and releasing distinct versions of a system. (Yes, it's from ITIL. But don't tell Eileen we use it ...) There is more to configuration management than just source control systems. Knowing how your project interacts with both the hardware it is running on and the other systems running on them is vitally important for a good CM strategy.
Quality & Defect Management It is important to establish quality priorities and release criteria for the project so that a plan is constructed to help the team achieve quality software. As the project is coded and tested, the defect arrival and fix rate can help measure the maturity of the code. Admin and Environmental testing is also very important for Admins! It is important that a defect tracking system is used that is linked to the source control management system.
Deployment This is where control of the project SHOULD be passed temporarily to your Admins This is what they do, so let them control the deployment of your application. If your testing has gone well, there should be no issues during this stage. However, DO make yourself available to the Admins during deployment, just in case this happens ...
Operations & Support Now that the application is Live, it needs to be supported. As a Dev your responsibility doesn't end when the application is deployed As an Admin you can't automatically blame the Dev if something goes wrong with the application Handover, support and escalation processes are now required so that both Devs & Admins know who is responsible for what elements of the application. This WILL make supporting the application much easier
Measuring Success The success of your project can be measured in many ways Both formally in terms that have been agreed before hand within the in definition of the project these KPIs will cover User Acceptance Whether the application met or exceeded the project specifications And... the often forgotten Administration opinion on the impact both positive and negative of the application on the platform(s) that it is hosted on Together these will define your team's success or failure on any particular project