Application or IT Environments Management

Note from Alec: I’ve copied this article here in case the original version disappears.

Author: Valentine

Application or IT Environments Management service will fall under Application Management as defined in ITIL2 (operational guidance) because it contributes to improving the overall quality of IT Software development and support through the lifecycle. Application Environments Management set encompasses a set of best practices proposed to provide an effective, end to end management service for test software platforms or development environments. The software test bed or development environment could consist of a client server application, Relational Database Management System (RDBMS), middleware, interfaces, daemons, customised processes (written in any software programming language), FTP utilities etc.

Functional test phases such as Unit, Integration, Acceptance, all manner of performance or non functional testing and development phases all require Application Environments.

The primary clients of an Application Environments Management service are Software Project and Test teams.

The service will cater for the following;

• Manage the creation, build, upgrade and support for all test and development Application Environments.
• Clearly defining auditable processes of allocating application environments, multiple bookings or shared usage, code upgrades, service level agreement, support, decommissioning and re-allocation.
• Manage data refreshes, collating test data and assist in the anonimising of production or other sensitive data if necessary.
• Supply, provision and manage all Application Environment Requirements from the Project and Test teams all through the software development cycle of a project.
• Assist the Project in establishing their application environment requirements, provide expert knowledge on the APPLICATION environment’s set up, connectivity and serve as a guide to the projects in using the application environment in the most efficient manner.
• Review and contribute to the Project Initiation Document (PID) ensuring that the IT Environments Management function and its deliverables are clearly defined and captured.
• Create and maintain project plans to assist in managing all activities required to successfully carry out major code upgrades to all application environments.
• Provide reports on usage/utilisation, availability, forward planning and schedules.

Application Environments Management is clearly a new and emerging area which has arisen due to the following reasons:

• The increased Application Environment requirements for many companies who have several software projects running at any one time.
• The increased levels of interfacing and connectivity between several systems in most organisations also known as spaghetti. For example in some companies more than thirty systems are interfaced or connected with each other exchanging files and data flows etc and has meant that any changes to one system most times could require a change to many others and then require large numbers of test and development application environments.
• Increased awareness and more commitment to carrying out rigorous software testing especially with more companies opting to use the Prince 2 methodology and ITIL Framework

A typical Application Environments Management tool should be able to provide the following services: environments bookings and allocation, manage multiple bookings and re-curring bookings. Provide reporting on usage, availability, interconnectivity or interfacing environments, utilisation and conflict reporting etc. It must also serve as a repository of all information on an Application Environment to include Host Server names, Hardware Type, Operating System, IP Address and Interfaces if any.

The ideal background for an Application Environments Management personnel could be Software Development, Application or Technical Support, Infrastructure Project Management, Configuration and Release Management etc but must be

exposed to at least the ITIL Framework, Client – Server development, System Architecture/Design, Networks, TCP/IP and Messaging systems etc.

Terminologies defined & explained:

Application Environment – A single test bed or development platform instance of a software application or system that can also be used for all manner of functional and non functional testing or could be the production instance (production environment). It could also be large, medium or small which normally refers to the size of data the RDBMS will be holding depending on the type of testing it is required for.

Integrated Application environments (also known as stripes): More than one application environment connected to each other also communicating with each other and exchanging files and data flows. Connections could be via Microsoft ODBC, via FTP, TCP/IP, daemons, middleware, defined interfaces and database links etc.

Anonimising of data

Anonimising of data refers to the manipulation or transformation of production data held in the RDBMS such as Oracle, SQL Server, Sybase, Microsoft Access, DB2 etc to be used in a test or development Application Environment ensuring that for example real names, addresses, date of birth, bank account details and other sensitive information or data is transformed to dummy data.

The data is transformed whilst still maintaining its defining characteristics in a Relational Database Management System table such as character length (Char 25 or Varchar 50) etc to ensure its usage in testing or development is not compromised and that the integrity is maintained. For example a valid name such as John Smith defined as Char 10 will now be updated in the table to become possibly a unique character string XXXXXXYYYY (comprising of ten characters including the space between John and Smith).

Pipe cleaning

Pipe cleaning caters for the all the activities required to be carried out before a test or development environment is handed over to the Test or Project team and includes disk clear down, archiving and purging logs, importing test data, killing off rogue processes, resetting passwords, changing environment settings, end to end connectivity or integration tests to make sure everything is working okay.

Depending on the complexity of the system a checklist of activities may be required and ticked off capturing all the checks and tests that have been completed on an environment or an integrated suite of environments prior to its hand over to a Project or Test team.

Smoke Test

A smoke test describes an initial end to end test of all the integrated or even stand alone environments very possibly using dummy data and carried out by the support teams who have created or built the environment or by the test team when the environment is handed over.

Article Source: http://www.articlesbase.com/information-technology-articles/application-or-it-environments-management-2884860.html

About the Author

• Freelance IT Environments Manager & Technical Project Manager

• Previously Global FX technology manager at Citibank International

• Worked in several sectors to include energy, utilities, Investment banking, railway transport, software development, healthcare, manufacturing, research, insurance and the gaming sectors.

My presentation on software process improvement

I recently gave a new presentation on Improving Software Processes at OSDC 2010 in Melbourne, AU

OSDC AU 2010: Get your papers in!

Updated 12/Oct/2010 — This proposal has been accepted so I hope to see you at OSDC 2010

 

The request for papers is up at The Open Source Developers Conference AU so get your ideas in. Here is my proposal for this year

Draft: Introduction to Simple Processes for Small Software Teams

N.B. This is an early draft of something I am currently writing. Please feel to comment and give feedback. The full ebook will be published in the next few weeks and I will follow with another blog so you can download it if interested.

How you can implement processes to improve quality, reduce stress and lower costs

Introduction

A lot of application development teams, and to a lesser extent operational IT teams, have either no or limited process. They depend on a combination of individual expertise, informal conventions and team habits (some good and some bad); and being prepared to put with all the problems of poor quality and unpredictability. It does not have to be like that and this ebook presents some ‘low hanging fruit’ you can pick to make your teams more productive – the approach is simple and practical.

This document is written for smaller teams who spend their time doing a combination of maintenance and new feature requests on an existing application. This actually covers the majority of software teams because, much as we all want to work on green-field projects and deliver Rel 1.0, most of our work is done on existing systems.

This ebook lists seven keys process areas (PA) that you need to think about: Metrics, Planning, Release, Testing, Issue¹ management, Version control and Communication. These represent broad headings across the Software Lifecycle than contain the low hanging fruit we can pick early and I chose them because we can (almost) focus in each PA individually. After some initial informal success teams can look to expand their improvement initiatives and use more formal and complex methods – which is beyond what can be covered in this short document. The resources section lists places that you should look for more information and different perspectives.

There is no magic to software process improvement – it’s a question of: common sense; team and personal discipline; patience; attention to detail; and a strong desire by everyone to improve the current situation. Also what works will require you to experiment and use judgement (obtained by experience) to decide what will work in your projects. There is no ‘one size fits all’.

Agile Processes : The tools and techniques presented here are written primarily for the benefit of more traditional teams. If you call yourself an agile team, but have no process then I recommend you engage a reputable agile coach; or take a step back into more traditional software lifecycle, improve your processes (using this ebook and other resources) and then step forward again.

1Issues in this context is a very broad term that covers requests for new features, bug reports, internal development tasks and questions

What is Application Lifecycle Management?

The analysts and tools vendors have been talking about Application Lifecycle Management (ALM) for many years now and I think they have (of course) been somewhat self serving in their definitions. ALM seems to  include whatever product category they have in the current price list and then promising their integrations’ would be managements answer to cost and governance issues. I hope to say more about integrations in the future, but I’d like to look at the scope of ALM for now.

If you ask vendors and consultants (including me) about ALM scope you’ll get answers such:

• Requirements engineering
• Software Configuration management
• Dependency Tracking
• Change control and work tracking
• Test management
• Software development tools and process
• Software building and processes
• Deployment
• Process Governance

Depending on the vendor you might even get more traditional: Project and Program Management;  Project and Application Portfolio Management/Analysis; and Service Management activities thrown in as well.

The usual sales pitch is that everything is managed via a common tooling and provides a common repository. The major, and often single, selling point of this approach is improved governance and business oversight of the SDLC.

However I think it’s useful and important to look at the definition of ALM from a customers perspective rather than as analysts or vendors.

It seems that a more pragmatic approach is to describe ALM as the methods, processes and tools that support the management of change for software systems — with particular, but not exclusive, emphasise on the SDLC. In this context it does not matter if we are using Agile or Waterfall approaches, we chose the best tools and processes for our particular situation. This of course implies that in eighteen months time we may need to re-tool.

Furthermore the methods tools and processes of project management (PM) are much more mature and there is no real need to include them in this evolving segment — they have their own. Obviously PM will have an influence and impact on ALM and we need to design our ALM approach to dovetail with it. I realise that most vendors will not agree with this.

I have come to the conclusion in order to ‘sell’ ALM into the teams that will use it we need to ensure, front and centre, that ALM provides a ‘better/faster/more’ improvement in daily productivity. That should be the primary focus of what is delivered.

Governance, audit etc should be secondary attributes and natural site affects of using ALM (important though they are of course and usually the primary sales message).

So at a practical level we need to be able to provide teams and their specialists with the best tools they need to do their job. Additionally we need to provide a supporting layer of data flows, events and data repositories to

1. Assist teams with traceability
2. Provide the tracking and management visibility to effectively steer the ship

So the point of this post is to plead with vendors to stop selling a one size fits all tool suite with deep integrations and start enabling shallow API and effective integrations to allow a truly best of breed approach for customers software purchases. It’s a shame that ALF project is shuting down.

Something I have been whining about for years

Syncable tools for the offline web

SD is a peer to peer bug tracker which can sync to itself, RT or Hiveminder. You can extend SD to sync to other bug tracking tools by writing simple adaptors. If you’d like to help make SD work better with your bug tracker, drop us a line.

With all the cool kids (and me) moving to distributed version control tools it’s been obvious that that there is a gap because our bug databases are centralised. Why is that a problem? Because code changes should always be booked against either a user story or a bug report. The link needs to be hard! i.e. I should be at least warned when I commit code without a ticket and when I look at a completed ticket I should be able to find the corresponding code. When you are committing code changes at 11,000 meters above sea level that can be a bit hard.

The only thing I know about SD is what I’ve read above, but already I want it!

[update 25/July -- the SD website now works so go for it!]

Installing a Serena Dimensions standalone system

Many Dimensions consultants, trainers and administrators have their own personal recipe on setting up a standalone Dimensions CM environment. Here is my latest:

An easy way to document process

What is a “Lightweight Ticket Process” ? « Alec the Geek

Document the process in some fashion. A process that is not documented can be very hard to talk about, agree and improve.

Following on from a brief twitter conversation with Kate this morning here is a simplistic example of how I currently document processes. The motivation for this approach is:

• Simple to edit and and maintain
• I hope simple to read and understand (even if you are not technical)
• Can be used as the basis for detailed work instructions

How not to market yourself on YouTube?

A company I know has released a promotional video on YouTube to explain their solution space. Whilst I applaud their initiative, I can’t help feeling they look like a bunch of sad 40 year olds trying to do the twist at an Eminem concert.

Sorry guys, a 10 for effort, but minus several million points for style

Or am I being really bitchy and unfair?

Intresting metric for predicting code quality

The Joel Test: 12 Steps to Better Code – Joel on Software

The Joel Test

The article explains it well and I have to say that it would make a very effective first test for team and process maturity. Try and see how well your team does…

Powered by ScribeFire.

Another blog than is not ashamed to say “Application Lifecycle Management”

Agile Software Process Improvement

Agile Software Process Improvement

I just found Jason Gorman’s blog (and his UML Tutorials). I am looking forward to reading more over the next few days.

Powered by ScribeFire.

UML for ALM Process Documentation

Some time ago I wrote about

Formal UML documentation for ALM Processes « Alec the Geek

the use of sequence diagrams to show higher level process

I at last got around to creating a very simple example

 

 

 

 

 

 

 

 

 

 

 

Powered by ScribeFire.

What is Enteprise Change Control?

Tool vendors love to talk about ‘Enterprise Change Control’ but what does that mean? Here are some attributes that I think define this label. Obviously there is further detail to be inserted behind each point (but hopefully all that will be revealed at OSDC)

• Captures everything
  E.g. bugs, questions, initiatives, enhancements,…
• Does not drop anything
• Does things the same (best) way every time
• Records risks and progress
• Authorises the risks and work
• Keeps historical information
• Is regularly reviewed for improvement
• Is appropriate for the task at hand
• Supports a clear “line of sight” from request to implementation
• Supports and reinforces the “Dimensions of Change”

Capturing ALM Metrics

Useful Software Metrics « Alec the Geek

Using a ticket management and capturing all issues, not matter where in our lifecycle they occur

Not all software teams have tools that allow metrics to be gathered. Without metrics we cannot answer questions about productivity, process improvement or estimating other than by (hopefully) intelligent guesswork.

How might we address that in the short term?

1. Introduce a time sheet system: That’s complicated and requires tools to analyse the data
2. Ask people to fill on project work sheets i.e. a time sheet for a project, rather than for an individual. It should be filled as each project work product is delivered (e.g. domain model,  fully dressed use cases, test cases, etc.). The sheets should be simple i.e. the deliverable, the project name, the project phase, dates and a summary total of effort and the number of people involved.

Armed with this simple information it should be possible to start gathering some more intelligent insights into how well the software process is working.

 

Powered by ScribeFire.

OSDC 2007

The Open Source Developers Conference 2007 call for papers has gone out and I have just submitted my paper proposal. Now all I need to do it write the paper and set up the demo’s… (if I get accepted)

An odd blog

Computer Math

Computer Math

I found this site, which has AlecTheGeek linked in their blogroll — many thanks for that. The site is a set of personnel technical notes and seems to be focused on software building and deployment. There is a lot of basic information, but it needs expanding with more personnel experience I think — could have lots of potential.

Powered by ScribeFire.

Linux Poster Boy Talks about SCM

Códice Software: Linus Torvalds on GIT and SCM

speech Linus Torvalds gave some days ago at Google, basically talking about GIT and Source Control Management

Codice Software have a nice blog entry about Linus’ presentation on Source Control Management. He does a nice job of expounding on the value of distributed version control — worth watching. There is further analysis by Kyle Cordes

However one question that is not obvious with distributed SCM is how to link commits to issues in the bug database. Do we we need a replicated bug database? If we we record the commit in a central database then we have a problem because we may not have access to the corresponding code…

Powered by ScribeFire.

Dimensions of Change

In the past when I’ve looked at Change Management issues I’ve tried to concentrate on lower level more practical topics. However recently I have the opportunity to think about change processes at the a higher level and of course that let me to want talk about it.

When looking at a change process it is tempting to see it as a single process, one size fits all, i.e all changes can be treated identically. However life is never that simple because changes have multiple facets. As well as identifying which change process needs to be followed, change dimensions provide information to assist us in prioritising work.

The most obvious difference, and the one that most people first come across, is the budget difference. Depending on who is paying for an change (IT or customers) has a direct bearing on the approval process. If the customer is paying (either directly or indirectly) then they, or their delegate such as the marketing department, must be involved in the financial approval to spend money. If it’s ‘free’ then the customer involvement may be limited to status updates.

A second dimension is size. The larger the size of the change the greater the process complexity and check points. How do we measure size? A variety of metrics need to be used, typically financial cost to implement, architectural impact on the software system, impact on other systems, how many project owners/stakeholders exist (this increases the issues involved in communication and resolving conflicting needs). This concept is reflected in the ITIL change process which recognises three levels of change impact and has different process flows accordingly.

A variation on the ‘financial cost to implement’ value is that different software systems may have different costs to deliver a similar level of business value. So a legacy application that contains a lot of cruft might cost $x to deliver y benefit, however in a different part of the business a different system might take a lot less than x dollars to deliver the same amount of value. So when comparing changes in a priority list, looking at a pure financial cost may not be enough.

The third Dimensions of change can be considered as political, i.e. who is sponsoring or controlling our changes? Often the executive team are able to generate a significant amount of strategic work which could absorb the all potential development and related resources. However an organisation also needs to exist on a daily tactical level and there are significant improvements to be made by implementing as many improvements to the current business as possible. However these changes often appear less significant to executive sponsors because of their more tactical nature despite their possibly huge business value.

When the various facets of a change are taken into account we can then make some decisions about the change e.g. Who will make the change, what level of process maturity will the change need to follow, which budget will pay for the change, who will be involved in acceptance testing, when will the change be released and so on.

Next time I will discuss some practical consequences of this and how to avoid some of the resulting pitfalls

Software Development: Where are you now?

When you start to think about a software project one of the things you absolutely need to know is “Where are we now?” (along with “Where do we want to go?” and “How are we going to get there?”). This question is usually not thought about that hard, and if the team have been working together for some time they generally “just know” anyway. However for an ousider it’s an important question to think about. I generally look for the following:

• What version control tools are in use and how is the information set up and used
• Is there any documentation of process and
• Does anyone follow the process documentation
• How do the customers feel about the work the team does – how do they think the team should change (that can be a hard question to get honest answers for)
• How are requests and issues documented (e.g. emails, post-it notes, bug tracking tool …) and how is the information used
• What is the technology used (e.g. frameworks, languages, build tools, IDEs, deployment …)
• What are the current ‘pain’ points (e.g. too much rework, too hard to understand code base, can’t refactor etc.)
• How much budget and autonomy does the team have

This will help you build an informal map to assist in in planning any work and identifying issues that may need addressing outside of the current project work. The information should be maintained in some easy to understand form e.g. a Mindmap or WiKi and updated every month or two.

I got a new book, Fit for Developing Software

FIT

Fit is a tool for enhancing collaboration in software development.

I just bought Mugridge and Ward’s book on using the Framework for Integrated Tests. I have only got as far as Ch 4 but I am very excited about how this approach might:

1. Help my conversations with customers by encouraging the use of Fit documents and
2. Reducing development overhead by making it easier to implement automated testing for business rules

I hope to get a chance to try this on some projects in the next 3-4 months so watch this space.

powered by performancing firefox