|
|
Printer management is tricky for a variety of reasons, and I’m not going to pretend I know all the answers. But what I thought I would do is discuss a few of the issues that make it so tricky, and provide a few tips and tricks that can make things easier.
That’s MY printer syndrome
People get very possessive about printers! I think because people hate having an existing habit disturbed, and walking further to the printer (whether it’s an extra metre or an extra 20 metres) feels like a marathon until you get used to it.
Personal printers are also a status symbol, and it can be very difficult to remove them, no matter how little they are used and expensive they are to support. Develop a culture where a personal printer is a privilege, not a right, and don’t allow anyone to inherit a personal printer when they move into an office – whip it out of there as soon as you discover the office is vacant, and never, EVER allow anyone to have an old printer because it is spare. You will never get it back and everyone else will want one too.
Another good tip is to network personal printers – it might seem like a waste of time, but believe me, personal printers breed like rabbits, and the only way you will have any ammunition for reducing their numbers is to be able to demonstrate how little they are used versus the support cost.
Old printers are expensive
Old printers are expensive to run, although they seem cheap – after all, they depreciated to nothing long ago, and they just keep running and running, like the Duracel rabbit. The expense comes in the cost of toner, which gets more expensive to buy as the printers become rarer, and the cost of electricity, as newer printers are much more energy efficient. Older models are also much dirtier (the cartridges allow toner to escape more easily) and more restricted in their capabilities eg not being able to duplex or print different sizes of paper, so there will be pressure for a larger number of printers in a smaller area.
Different work roles have different printing needs
The type of documents your users print can make a big difference to printing needs. For instance, a lawyer who prints off a large document of a hundred pages every day will have very different requirements to a book keeper who prints off a hundred one page invoices. The lawyer won’t mind (too much!) walking to the MFD at the end of the corridor, but the need to do so for the bookkeeper would seriously affect their productivity. It is perfectly reasonable that they should have a printer closer to them so they’re not making so many trips just to pick up print-outs.
Having said that, there may be a wider issue of why the person must print out a hundred one page documents a day. Are they manually entering data from one application to another (but what about the inherent the data-entry dangers)? Are they comparing data in different documents (perhaps a larger monitor might make it easier for them)? Are they printing out documents in order to keep a hard copy record (maybe they should use an electronic archive instead)? It may be worth asking a Business Analyst to spend some time with the person to see if there is anyway that their work can be streamlined and productivity improved in general, as too much printing can be a symptom of other work inefficiencies.
There are no hard and fast rules
All these factors mean there are no rules by which to judge whether you have achieved the optimum printer environment. The number of printers required in any given space will be a function of the number of people, the distance to the printer, the type of printing they do and the culture of the organisation. Analysis of the print environment should be ongoing and constant to try and minimise the number of printers and associated support costs.
Has anyone had any experience in designing the optimum print environment? What factors did you consider when making your judgements?
 So as promised, here are my top tricks for effective management of support, maintenance and subscriptions. They are in no particular order!
Storage
Support, maintenance and subscriptions are all types of contracts. You should scan them in for your own reference and as a back-up, and send the originals for storage by the legal department in their fire-safe.
Use a tickler file
A tickler file is any system, whether electronic or in paper format, that you use to remind you that an agreement needs renewing. The benefit of electronic tickler files are that they can be set up to send automatic reminders to relevant parties, but the drawback is that if a key recipient leaves the organisation, the reminder can disappear into the ether and the contract doesn’t get renewed. If possible, store your scans/photocopies of the contracts and any other supporting information in the tickler file so that they are easy to locate when needed.
Centralise contract management and administration
IT Techies are just plain awful at administration. Centralise it as much as possible into a skilled, coherent team so that you have continuity of administration and regular transfer of knowledge and skills between team members. A key function of the team is to ensure that the entire purchase and renewal process is tracked from renewal reminders being sent out to requisitions and POs being raised and invoices paid.
Request a business case for renewals
The business case doesn’t have to be exhaustive, but it does need to demonstrate that the key decision maker has thought through the options available as well as the implications and risks of renewing or not renewing the agreement.
Co-termination
Where you have several agreements with one supplier, request that they all be co-terminated – in other words, that all the agreements have the same renewal date. The first year may require some pro-rating of renewal figures by the supplier, but they are usually happy to do this. Many software manufacturers insist that the first year be paid in full before the agreement can be co-terminated, but you will be able to pro-rata and co-terminate the agreement the following year.
The benefits are two-fold – firstly, it leads to significantly reduced administration and management costs, and secondly it allows decision makers to see the full picture for any one vendor at a time, leading to better and more considered decision making.
So those are my top tips – does anyone have any others they would like to add?
Picture Credit: Penny Buckmaster
 Are you going to be surprised when I tell you that Support, Maintenance and Subscription arrangements have a lifecycle too? I didn’t think so!
New Agreements
Most of these agreements are entered into as an adjunct to the purchase of a piece of hardware or software, although subscription licenses are the actual license, but paid for on a regular basis rather than once off.
The factors behind the decision to purchase a subscription license are similar to the decision behind purchasing a perpetual license – essentially it is just the form that is different. The decision to purchase subscription vs perpetual will depend on comparative costs, the longevity of the license, management costs, and, interestingly, whether the organisation capitalises software costs, or writes them off as expenses… but I’m not going to talk about that in any more detail here.
Just as there is a decision to actually purchase hardware or software in the first place, there is the decision to enter into a support and maintenance contract. The decision is usually independent of the purchase, except for some software titles, where the purchase of support and maintenance for the first year is often compulsory. The decision to take out a support and maintenance contract will usually be made as a result of discussions among the techies, management and procurement, and will be based on cost of the support or maintenance, in-house expertise, desired service levels, and whether or not the purchase (or non-purchase) would affect any other, more vital support and maintenance – remember what I said last week about some software companies taking the ‘all or nothing’ line that if one active license isn’t supported than none are!
Lifespan
The key difference between support, maintenance and subscription agreements and the purchase of a piece of hardware or a perpetual software licenses is that it must be renewed on a regular basis or it will lapse. The decision whether to renew the contract is based upon similar factors as the decision to take it out in the first place,such as the importance of the hardware or software, in-house skills and desired service levels.
For most organisations, the biggest management challenge is to implement processes that ensure the contract is flagged up as being due for renewal, and that the whole renewal process is followed through to its conclusion, including final confirmation that the contract has been paid for and that the suppliers is also in agreement that the contract has been renewed.
Support, maintenance and subscriptions are intangible assets just like perpetual software licenses, and so similar care should be taken to run regular open PO and unpaid invoice reports in order to identify any problematic transactions. Another thing to bear in mind, particularly for subscription licenses and software support and maintenance, is that some manufacturers will expect you to be able to show evidence of a continuity of support in order for the current support to be valid. This is is to discourage organisations from taking ‘time out’ in a support or subscription contract, and if a license ‘falls out’ of support, the manufacturer may sometimes charge a penalty fee or ‘uplift’ for the privilege of putting it back into support.
End of Life
At some point the hardware or software that is supported will no longer be required by the organisation, and the support contract can be ended. Most of the time, companies will just let their support lapse at the end of the period, but large and/or very long term contracts may need to be actively terminated, and a refund of fees paid may be due.
On the other hand, subscription licenses may be at the other extreme, and have a penalty charge applied for ending the contract early, like mobile phone contracts. And of course, particularly with software support and maintenance, you should be sure that cancelling the support and maintenance will not affect support and maintenance for other licenses because the manufacturer has an ‘all or nothing’ policy.
So that’s the lifecycle of support, maintenance and subscription license agreements. Next week I’ll outline some tips and tricks for managing them effectively.
Picture credit: Kylie Fowler
I hope everyone had a good Christmas and New Year! Mine was… interesting… to say the least, as I was visiting my brother’s in-laws in the South of Italy. Highlights of the stay included helping with the slaughtering of two pigs and processing the meat for salami and hams! Very cultural to say the least, and, believe it or not, a very welcome break from IT Asset Management.
But anyway… back to work.
Subscription licenses, support and maintenance all have one thing in common – that is, they need to be renewed regularly. Like perpetual licenses, the rights involved are intangible assets, which means not only can it be difficult to prove that they have indeed been legally purchased, but unlike perpetual licenses, the right to use the software and take advantage of support and maintenance needs to be renewed, usually by means of a contract renewal and payment of a sum of money, on a regular basis.
Let’s look at these beasties in more detail.
Subscription Licenses
Are, like an ordinary perpetual license, the right to use a piece of software within the terms and conditions in the contract. If the subscription is not renewed at the end of the period, then the right to use the licenses expires. Sometimes an option to convert the subscription licenses to perpetual licenses is included, generally, of course, exercisable on the payment of more money!
In addition to all the standard SAM dangers of over-installation and under-licensing, there is the additional danger that the contract is not legally renewed and so the right to use the software lapses without the organisation being aware they are no longer compliant.
Subscription licenses are becoming more common with the advent of Software as a Service and Cloud computing. These application delivery technologies allow the software manufacturer much greater control over who uses the software and when, therefore reducing the risk of a subscription lapsing while the company continues to use the software.
Support and Maintenance
I’ve discussed support and maintenance in the context of ITAM lifecycles before, but lets look at them in more detail from a management point of view.
In an IT context, Support Contracts give an organisation the right to contact the support provider for assistance if they experience any problem installing, using, upgrading or de-installing a product (whether hardware or software), while maintenance contracts give an organisation the right to request that a piece of hardware be repaired if it breaks down, or in a software context, to install software patches and bug fixes. Occassionally maintenance contracts will also include the right to free software upgrades, but as always, it depends on the detail of the contracts!
Support and maintenance contracts are often purchased together. While software Support and Maintenance is almost always purchased from the Software Manufacturer, hardware Support and Maintenance contracts can be purchased from independent third parties who may offer lower prices and/or better service than the original manufacturer.
Support and maintenance contracts generally run for a period of either one or three years. Discounts are often given if the contract is taken out for the longer period.
Although the financial risk in accidentally letting a support and maintenance contract lapse is not generally as high as with accidentally letting a software subscription license lapse, there are still significant risks involved.
First and foremost are the service management risks inherent with something going wrong with the hardware or software and not having an expert available to help resolve it quickly and with minimal disruption to service levels.
Because Support and Maintenance are such important revenue streams for software manufacturers, who also have a monopoly on providing the support and maintenance, the software manufacturers also have the ability to demand continuity of support and maintenance for their products. By this I mean (and in contrast to hardware manufacturers where there is thriving competition in support and maintenance provision) they have the commercial power to demand that any software that is supported should be supported continuously throughout its life. There will often be penalty charges to bringing licenses back into support if the support contract has been allowed to lapse at any point in time. Some manufacturers, particularly of high-value software, will also insist on an ‘all or none’ policy for currently used licenses, meaning that if the support on one currently used licenses lapses, it invalidates the support on ALL currently used licenses. Not only is that a huge service management risk, it is also a financial risk, as you may have paid a large sum of money in supporting several such licenses, only to have it invalidated because support on one license was missed in the renewal process.
As you can see, managing renewals of subscription licenses and support and maintenance is not only very important, but also poses a challenge because of the intangible nature of the rights purchased and the need for renewal of the rights on a regular basis. The next couple of posts will look at techniques to help manage these contracts.
As we’ve seen, software deployment and upgrade maintenance functions tend to follow the same set of processes. We’ve also seen that because software is just code that can be updated and changed easily over a long period of time, it has a much longer lifespan than hardware does generally.
 But software will come to the end of its life sooner or later. Often it will just become too difficult to continue updating it, so a completely new piece of software will be adopted. Other times the function for which it was originally designed is no longer required and so neither is the software. The mutually reinforcing technology cycle where more sophisticated hardware requires more sophisticated software which requires more sophisticated hardware also plays a part.
The decision that software is no longer required is generally an architectural one. By this I mean that the decision will be made by the people who manage the IT infrastructure of an organisation to ensure that it meets ongoing needs. The decision to discontinue a piece of software will be based upon input from users, tech support, and the developers who may have been upgrading the software. Non-technology areas such as procurement and the Legal department may also contribute to the decision making process. Other things that will be considered are what alternatives are available and how much they would cost, both in terms of creating / purchasing the software in the first place, and also how much it will cost to maintain / update the software over time.
Once the decision has been made to remove a piece of software, the software needs to be uninstalled from machines. This can be either be a manual process – very time consuming – or it can often be done automatically using a software deployment tool – yes, these tools will generally be able to automatically uninstall software too!
Sometimes software can be difficult to uninstall, particularly if it is older, or hasn’t been designed well. Sometimes software can leave traces in the registry which can be difficult to remove, and older software, particularly, may never have been designed to have an ‘uninstaller’ which will remove the application from the machine without affecting other software. Thorough testing should always be conducted before a piece of software is uninstalled to ensure that the uninstall causes no problems. Occasionally software that does not uninstall properly will leave a ’signature’ in the registry or add/remove programmes which can fool a discovery tool into thinking the software is still installed. This can confuse licensing positions, and is another reason why thorough testing should be carried out before uninstalls go ahead.
Another big challenge faced when uninstalling software from an organisation is similar to one faced by Patch Management – the need to ensure that the software has been uninstalled from all required machines. As with Patch Management, software asset management tools can provide us with the information we need to check the uninstalls have been completed.
As with the situation where a discovery tool is fooled by poorly uninstalled software, software that we think has been uninstalled but is actually left on machines can have serious implications for the license position of the organisation.
This has just been a very quick run-down of some of the issues to take into account when software reaches its end of life. Next we’ll take a look at the finance implications of the software lifecycle, with a focus on how to manage licensing at each stage.
Picture Credit: Kylie Fowler
 The software lifecycle is truly circular – unlike hardware which may be repaired only once or twice in its life, software will often go through many iterations of improvements (bug fixes, new functionality etc).
Most of the activities involved in the upgrade of existing software are exactly the same as those involved in creating and deploying the software in the first place. There will be cycles of developing and testing before the changes to the software are deployed. The deployment process is also pretty much the same – identifying machines to be upgraded, actually installing the upgrades, verifying the installs have been completed and ensuring that no machines have been missed.
Really, that’s it for this post, but f you can think of anything to add, tell me, because it does seem very short. I’ll look at the financial aspects of software management a few posts down the road, so don’t start getting stressed if you feel I’m only covering half of it – have patience!
Picture Credit: Penny Buckmaster (I wish I’d taken this one, it’s a great picture)
 Software gets installed on machines in a variety of ways, and for a variety of reasons.
Controlling Software Deployments
In general, it is installed because someone wants to use it. However it can be a challenge ensuring that the value gained out of the software is more than the cost of the software. Most organisations have some sort of authorisation process in place to ensure they receive value for money out of their software. Individual software requests may only require line manager approval, but large deployments will often be treated as projects and go through standard governance processes.
Software can also be installed because it is required, for instance if the software patches a security hole or fixes a bug in an existing piece of software. It may also be installed as part of an upgrade programme.
Ad hoc software requests of the “I need to use this piece of software, please install it” kind) are usually treated as a service request which will be routed through the service desk and fulfilled by desktop support as a “standard change”. Deployments which affect a much larger group of users or machines, such as a patch, bug fix or upgrade programme will usually go through change and release programmes to ensure they are installed on all machines that need the software, that the installation doesn’t cause problems with other systems, and provide a ‘back-out’ path in case things go wrong.
Exception reporting is vital to ensure that all users or machines that were intended to receive the software actually do receive it, and that no one ends up with it who doesn’t need it.
Packaging
Common applications, including Operating Systems and the components of a standard build, may be installed on a server as a ‘package’ so that they can be installed quickly and easily on selected machines. All software that is packaged should go through the same testing process as any other piece of software and should also be subject to the same controls.
Tools
There are many tools on the market which assist with software deployment, and indeed many are part of a suite that also include a software asset management tool, for instance Altiris. There are also some specialist deployment tools which are part of a security suite and which focus on Patch Management, although the technology behind these tools are fundamentally the same as any deployment tool.
Deployment tools are only as accurate as the hardware management that supports them (making sure that all machines are on the network regularly, have the relevant agents installed and working, that machines intended for salvage are removed from the pool of machines etc) and also rely heavily on the accuracy of associated discovery tools to identify which machines have had the software installed and which need to have it resent to them.
Uncontrolled Deployments
Despite an organisation’s best efforts, it can be very difficult to ensure that all software that is installed is done so through the correct control procedures. It was a challenge in the days of ’sneaker-net’, when software had to be installed using physical media, but the ability to download software off the internet has made the problem acute.
The surest remedy is to ‘lock-down’ all desktop computers so that only an administrator can install software, but even the most controlled of companies will have computers that are not ‘locked down’ for whatever reason, and it will always have people who know the administrator password which gives them the ability to install what they wish. Again, exception reporting is the key to identifying uncontrolled software installs and initiating processes to have it removed.
So this is a quick run down of how software actually gets installed on machines – but you’ll notice I haven’t even mentioned licensing! That’s because, although all software will have some sort of license or intellectual property rights associated to it, in many, many cases the license will be such that the software is effectively uncontrolled from an organisation’s point of view – for instance patches, bug fixes, drivers etc. These are all pieces of software that have perfectly legitimate reasons to be installed, although the license does not need to be actively managed.
I’ll talk more about techniques for managing those licenses that do need to be managed in later posts.
Picture Credit: K J Fowler
Unlike hardware, software never wears out, although it does need to be updated regularly to ensure it keeps meeting the needs of its users as well as patch any security holes that may be discovered.
In my previous post on the origins of software, I looked at the main groups developing software and some of the drivers behind the regular updates that are required for software. In the next few posts I want to consider the software lifecycle from the point of view of organisations, and consider the implications for IT Asset Managers.
For most organisations, software will enter the organisation in one of two ways – it may be bought in having been developed by a third party (either commercially or by the open-source community), or be developed in house.
Requirements Gathering
Either way, the organisation needs to determine what requirements the software needs to fulfil. The requirements gathering team must then assess third-party software to ensure it is a suitable fit, or must design the software that is to be developed in-house. Business Analysts and Business Systems Analysts will generally be involved in both scenarios, essentially translating business requirements into technical requirements that allow IT to make the right software purchase, or develop software with the appropriate functionality.
Cost is, of course, an important consideration in both scenarios. For commercially produced software, the cost of licensing and on-going support and maintenance charges is an important consideration, for open-source software, support will form the bulk of the cost, and for in-house software, the cost of both the initial development, as well as ongoing support costs, will need to be taken into consideration.
Software Asset Managers will generally be called upon at this stage of the lifecycle to provide information as to both the current and long-term implications of different licensing arrangements in order to assist the organisation to make the right decision about which software to purchase and how it should be licensed.
Software Assessment
If a decision is made to purchase third party software, several different applications may be assessed to determine which is the right choice. At this stage of the process, it is important that correct licenses are purchased and that they follow normal SAM processes to ensure that the organisation is compliant. For this reason it is important that project and technical teams are given SAM awareness training and understand that they need to bear in mind SAM issues when planning software assessment.
Software Testing
Once the decision has been made as to what software should be sourced or developed (and development has actually occurred if it is in-house software), the next step in the process is a thorough testing of the software to make sure it functions properly and doesn’t cause any problems with existing systems. Software Asset Managers aren’t generally involved directly in this process as it is more a technical matter, but again, they must ensure that appropriate licenses are purchased and are managed in accordance with the organisation’s SAM processes and policies.
Once software has been thoroughly tested, it may be approved for entry into the production environment. This process is deployment, and we’ll look at that in more detail in the next post.
 Idealized Design I ordered a couple of Russ Ackoff’s books after I wrote the post on Systems Management the other week. One of them has arrived, ’Idealized Design’, which I am finding very interesting (although as you can see, I am a little schizophrenic about the ‘z’ in the word idealised)!
In essence, Idealised design asks companies to imagine that everything in the system they are redesigning was destroyed over night, for them to design the ideal system that they would like to see magically created overnight.
There are a couple of rules – what they design needs to be technologically feasible today, and the design teams create what they want to see in place today, ignoring what they think might happen in future.
Then the design teams work to put in place their ideal design.
Of course it isn’t as simple as that, but even so it is pretty powerful stuff, and I think it will be an invaluable technique to add to my SAM toolkit, especially when working in complex organisations that are struggling to make the leap from reactive to proactive SAM.
Here is an excerpt from the book I’m reading, which beautifully illustrates the origin of the technique and gives a good idea of its power: http://knowledge.wharton.upenn.edu/article.cfm?articleid=1540
Before we try and understand software lifecycles in depth, I thought it might be useful to think about where different types of software come from – why are they developed and what are the drivers for change.
Software seems to originate in three different ways:
Commercially produced software: Almost all organisations, no matter what their size, will purchase the right to use standardised pieces of software from software manufacturers (eg Microsoft Office, Adobe Acrobat etc). These pieces of software tend to have a very defined function that will be required by many organisations and individuals – for instance word processing (MS Word) or minimising the size of files before emailing (Winzip). Generally these applications will be self-contained (needing little or no additional development to function effectively), and the source code will be closely guarded by the manufacturer, which allows little or no customisation of the application. For most people, this is the most familiar type of software, and it is the management of these applications that forms the bulk of license management work. ‘Off the shelf’ applications will generally be ’supported’ by the manufacturer which will regularly provide patches (ad hoc improvements to the software to ‘patch up’ bugs or security issues with the software) and upgrades (planned improvements to the functionality of the software) to those users who pay maintenance and support. Implementation of the software and any patches and upgrades is generally fairly straight forward and most problems encountered by individual users will be able to be rectified by the organisation’s in-house service-desk structures.
Some commercially produced software is so large and complex that structures must be put in place within an organisation to implement, customise and support them that are very different from that of normal ‘off the shelf’ software. For instance, Enterprise Resource Management (ERM software) such as SAP and Oracle, which many firms use for their finance and HR/Payroll systems, will require an ecosystem of developers and administrators to customise the software, keep data accurate, and provide dedicated application support to users of the software. Any large, complex piece of software that is heavily customised may also develop a similar ecosystem, for instance Altiris or BMC software in the ITAM field. In general, new development work (ie patching and upgrades) will be carried out by the manufacturer, but ongoing customisation and support beyond that included in the contract with the manufacturer may require dedicated in-house or out-sourced resource.
Regular enhancement of commercially produced software is driven by two different things – the need to patch security holes as they are discovered, the commercial imperative to maintain and capture market share as many software manufacturers operate in an extremely competitive environment. The fact that income streams from support and maintenance are an increasingly important source of revenue, and that ‘free’ or reduced cost upgrades are a standard benefit of support and maintenance almost certainly also encourages innovation!
**Disclaimer** I work in the commercial world and know an awful lot more about commercial software than I do about any thing else. If I get anything wrong in either of the next two sections, then please correct me!!
Open-source software: is software where the source-code is published under a license which freely allows developers and companies to make use of the software and its original source-code as they wish. The most common example is the Linux operating system, and the most common license that open-source software is published under is the GNU General Public License. Open Source software is developed and updated by a community of developers who generally do their work for free, as a hobby, with ‘payment’ being the satisfaction of being part of a community of peers, and gaining kudos from that community for doing excellent work eg creating a patch or developing new functionality of the software.
Although the actual source-code of Open Source software, along with any patches and upgrades is made freely available under a ‘copy-left’ license such as the GNU GPL, organisations will often find that they need technical expertise to customise the software as needed, and install the patches and upgrades and make sure they are all working properly. Sometimes organisations may employ developers and administrators to do this in house, while other organisations may pay an external company to this, for example RedHat. So although Open Source software is ‘free’ in the sense that you have the freedom to do what you want with it, it isn’t really free in the monetary sense of the word.
Freeware and shareware are pieces of software that act more like individual ‘off the shelf’ applications. Often these applications may be licensed under their own license which may request a donation, or specify that the software is only free for individual use, and that corporations much pay a license fee. It is always important to read and understand the specific terms and conditions of these licenses before using them.
Like commercial software, open source software needs to be regularly patched as security holes are discovered. Innovation in open source software is driven by the developers themselves, who have an idea or need and then design the software to fulfil it. This has led to some ground breaking applications, particularly in areas relating to the internet, which is a vital tool for the collaborative effort involved in open-source, as well as in the production of new developer tools. These days, I suspect, a lot of innovation in other areas is also driven by the desire to provide an alternative to existing commercially developed software, as well as by companies who design software for commercial reasons but using open source languages and techniques.
Bespoke Software: some organisations gain their competitive advantage from the development of bespoke software. Obvious examples are software manufacturers such as Microsoft who are in the business of designing software for profit, but many other organisations with sophisticated business models also find that it is in their interests to develop specialised software in-house. For instance an investment company may design specialised trading software to help it make decisions about what shares or commodities should be traded and when. The copyright and ownership of these applications will reside with the organisation that developed them.
In the past much bespoke software was designed from scratch, using programming languages such as C+, but these days organisations are more likely to develop applications from commercially available building blocks. For instance, an on-line retailer may build an application to sell its goods based upon an Oracle database to store the data and an html front end (designed by a web designer in house) to allow employees to make changes to pricing and what goods are on offer. This may then be hosted on a Linux-based internet server again with an html front end to allow customers to buy the goods.
In this example, a license will need to be purchased for the use of the code that is the foundation of the Oracle database, but the design and structure of the database will remain the copyright of the company that developed it. The flexibility of certain commercial software (SAP software for instance), and the ubiquitousness of the leading database manufacturers (eg Oracle) means that the line between the processes and skills required for development activity for the large commercial software and bespoke software is getting more and more blurred and so it can be difficult to know what ’software development’ actually refers to. This matters, of course, because the ownership of the underlying intellectual property is different in each case – on the one hand it belongs to the the commercial software manufacturer, and there is likely to be a requirement to pay license fees, while on the other, it belongs with the company that developed the software, and there will be no license fee payable for the software itself, just on any underlying databases or commercially developed applications.
The most obvious driver of change for bespoke software is the need to ensure that the software changes to continue to meet the needs of the business as the business changes. But there is another, less obvious driver of change, and that is the need to ensure that the underlying technology – both commercially produced software (eg databases) and the hardware it sits on – can be supported and are compatible with the other hardware and software they need to work with.
It is amazing how many vital business processes use old pieces of software that, because they are code rather than hardware, never break down and all unnoticed keep working away serving the needs of the business. Many businesses fall into the trap of not ensuring these old pieces of software are up to date and one day the 10 year old server the old software is running on breaks down and they can’t get spare parts for it – disaster! Or they may find that one part of the business has upgraded a piece of software but the old code is no longer compatible with the new software and it stops functioning – another disaster!
As an aside, in ITIL, it is Service Catalogue Management and Service Asset and Configuration Management between them that are supposed to understand these relationships, while Release and Change Management are the ones tasked with ensuring that keeping everything up to date goes smoothly.
As I’m sure you’ve noticed, change is a constant theme in technology – which is why IT is such an exciting area to work in – and in my next few posts I want to explore the whys and hows of software change ie the software lifecycle.
|
|
Recent Comments