Sober Counsel

A custom smart client can go a long way to addressing your Software factory needs and is in my opinion one of the most effective ways of reducing ongoing development effort.

A Smart-client can address many non-functional or repeating-requirements that will not have to be developed ever again.

Smart-Client Administration
An administration Interface for the smart client is essential to take admin away from the developers and hand it over to the support desk. For instance adding a new user or promoting a piece of functionality from Testing to Production can be done via an administrative interface. Within this client we embed a lot of functionality that would previously have been done by developers. I include Authorisation, creation of Data access aliases (See section on Data Access Agent), upload of new functionality into the Smart-client database, promotions between Development, Testing, Production etc, notifications to authorised users, work-flow definition and edits, creation of aliases to access functionality (menu-item naming) and any other administration whether done by developers or support-staff. I also recommend that the admin tools be built as functionality that snaps into the smart client itself – it just makes it easier.

Authentication / Authorisation
If your organisation uses a directory service of some sort, then integrate the smart client into the directory for authentication. If you have a generic authorisation services, then use that to authorise the client functionality as well. if not, link the IDs of your directory user into an authorisation table accessed by the Smart client Administration interface to link users to the functionality they require.

Work-flow
If your organisation uses work-flow, then definitely link generic work-flow functionality into the smart client so that it too is dealt with once.

Data Access Agent
If your smart client allows plugged-in code to access data directly, then you are missing a trick here. This idea has very powerful side-effects.

Define a method by which plugged-in code asks a function provided within the smart client for some data. The smart client should then source the appropriate data and return it to the calling plug-in. Some side-effects here are that the developers need not know any of your production database user-names or passwords, and you can within the smart-client infrastructure redirect data requests to other destinations (for example to your disaster-recovery site, or a testing database)

In the implementation I have built previously, we created a lookup-table for data-sources that indicated an “allowed calling-plug-in”, “operational-mode” a “Data-source alias” and the details of each data source. This allowed us to automate a switch to “Disaster-Recovery” mode through using a predefined “operational-mode” called “DR”. The Smart-client had a process for checking against a centralised web-service for which mode it should be operating in for a particular application. The flexibility here was staggering. This also means that the change management team can promote an program from Testing to Production without any help from a technical team whatsoever.

On-line/Offline modes
A web-based client or portal has the disadvantage that offline modes are not possible or at least very difficult to implement. A smart-client can do this fairly easily and with the “data-access agent” functionality above it is even easier to achieve.

Code Generators
I have found that most user interfaces that we needed to build were in fact forms that interacted with data-tables. We used a multi-tier architecture where the front end was smart-client (containing a data-access layer), a business layer consisting of stored procedures which performed a lot of the business activities and which interacted directly with the data-tables. So we created a form-builder that created both the stored procedures and .NET forms automatically. We would point the tool at a set of data-tables and lookup tables do some configuration and click “GO”. What we got out was a stored-procedure that conformed with all the rules we had predefined and a .NET project with all the necessary forms and the interactions with the Data Access Layer and Stored Procedures. If there were no fancy custom UI interactions nececessary we could simply compile the project, and upload the DLL into our smart-client database for testing.

So no developer-time required for:

• authorisation,
• basic form-based UIs,
• access to data,
• Disaster recovery implementations,
• promotions between Dev, QA, Prod etc,
• Creation of menus
• Creation of custom workflows

among others. This represents a significant saving in the development stage of any project.

Technorati Tags: Software Factory, Development, Custom Code, Code Generation

Tags:   Smart Client · Software Factory5 Comments

There are a number of ways to implement the Software Factory Principle (Remember the principle says that any method to enable mass-production of software (especially standardized non-functional requirements) at a lower cost and in a shorter time constitutes a software factory of sorts.

Here are a few of the more common approaches:

1. Service orientation
Common Services (standard non-functional requirements) are implemented as SOA services. These need to be understood and published so that developers are aware of which common services they can use and exactly how to use them. SOA provides standard ways of doing this. The effect is that code should only be written for explicit functional requirements as the critical-mass of standardized non-functional requirements can be built up as needed.

Strengths

• Very loosely coupled
• Changes to a common module are immediately available to consumers
• Source-code for common services need not be seen by external developers, only the contracts for using these services needs to be known.
• Allows parallel development efforts, provided development of common services is well managed.

Weaknesses

• Governance of deployed common services is complex to manage

2. Smart Clients
The non-functional requirements are coded into a smart-client that exposes a library of functions to the functional modules which simply snap-in to the smart client framework.

Strengths

• Code for the non-functional requirements need never be seen by external developers, only the calls need to be known.
• Code executes in a distributed environment with greater flexibility to provide performance requirements.
• Allows for extremely parallel development efforts, while maintaining a common framework.
• Will scale very well.

Weaknesses

• Need to deploy the smart-client to all users when changes are made to common modules.
• Fairly tightly coupled, although functional requirements could be deployed as SOA services.

3. Common Code Libraries only
This method simply relies on the developer to re-use code from a common code library.

Strengths

• Ensures common approach to standard problems

Weaknesses

• Relies on the discipline of the developer to use the standard modules and not code their own version
• A Change to a standard module would require that all applications using that module would need to be recompiled and tested.
• Very tightly coupled.

4. Monolithic Applications
SAP for example is a single Uber-application that has many modules and performs many tasks. All of the non-functional requirements are standardised and cannot be changed. If one were to be changed, it would automatically be changed for all the other functional modules. All of the non-functional requirements are already coded into the SAP application and adding functionality involves coding the functional requirements only.

Strengths

• Similar to the Smart Client approach

Weaknesses

• Businesses can seldom function on a single piece of software
• This software will become extremely complex
• Very tightly coupled

Summary
There are numerous ways of deploying the Software-Factory Concept to speed up delivery of functional requirements, each with its own strengths and weaknesses.

I recommend either of the first two approaches (Service-orientation or smart-client) or a combination of the two. These provide most of the benefits of a software factory and less of the drawbacks.

Note that they have a management overhead. If they are not managed properly you will gain little benefit or in extreme cases if very poorly managed you may end-up worse-off than you were when you had discrete unmanaged code for each application.

Technorati Tags: Software Factory, Development, Custom Code, Code Generation,

Tags: No Comments.

Software Factories: Part 2 will be coming along on Monday, but for now a change of topic onto Systems Management

Out-of-the Box Systems Management Tools
There are numerous systems Management tools out there and a lot of corporates own a lot of diverse instances of these. Each one has its place in the market and plays to its particular strengths and has certain weaknesses. For example one might come already configured with everything you need to manage server harware, but may not be customisable to manage routers at all. Another tool may be completely generic and may be able to manage any device or system, but it comes preconfigured for almost nothing and you have to put the time and effort in to configure all the threshholds and metrics that you want to measure for each item in your environment.

Where is the Value?
The question is loaded of course and the answer is: “It depends”. If I am a Mail administrator and I want a system management console to tell me how my mail-system is doing then I would see little value in buying a completely generic tool and customising it to tell me how my mail system is doing. I would have to do extensive research and determine what the metrics are that I should typically be concerned about and what there respective threshholds should be in my particular setup. Over time I could tweak these until they are just right for me. Yuck. What a waste of time. I could just buy a specialised monitoring tool that tells me exactly what I need to know about mail-systems with all the threshholds already set. WRONG.

KNOW YOUR ENVIRONMENT
If you bought a specialised mail-monitoring system you would still have to customise all the threshholds and metrics for your specific environment because your servers may be scaled differently, your mailbox structures may be configured differently etc. If you make the mistake of leaving all that up to the manufacturer of the monitoring tool, then the chances are you will be ignoring most of the info the system produces and eventually say “This thing is always wrong” and untimately it will fall into disuse. Ok that’s a worst case, but my point is you need to KNOW YOUR ENVIRONMENT. There is definite value in researching what metrics are relevant for YOU and what the appropriate threshholds are in YOUR environment. So am I saying there is no place for specialised tools. Not at all. As long as you recognise the responsibility stays with YOU to manage YOUR environment, and cannot be delegated to a tool.

Where is the Value?: Part 2
If I were a departmental manager or executive, my requirements of a management system would be completely different. I would want a very general overview of the state of affairs in the organisation. In fact I would want period summary reports and would probably never look at a realtime console. So the requirement is completely different. If the underlying monitoring systems contributed their information into a centralised warehouse, I could draw a report off that and get what I needed.

Caution: Information Overload in progress!
The question is WHAT INFO DO I NEED? That is the RIGHT question (see iRobot – the movie) to start with. Too much information can be as useless as no information, except that now you have spent money on tools (and support staff for those tools) to produce that information that you never look at. Exactly the right balance of information is critical, especially in large environments.

I used to look after all the servers for a medium-sized corporate and after about six months of harassing the systems-management guys I had exactly the reports that I wanted. I sent a monthly report to the senior IT managers exhibiting the outages and incidents that occurred with a comment from myself on each. I also had a weekly report summarising the top 10 major potential and real issues across all servers. Each week I tried to deal with the issues on the top-most-unhealthy server. I also had a daily report on the configuration and health of each server, which I archived and kept for 3 months, which I only looked at if I needed to research something later (reading that report daily would have been overload).

It shouldn’t be easy
My parting comment is that you need to get to grips with your environment and do the investigation and research into what it is that YOU need to manage in YOUR enviroment. It is extremely unlikely that someone can do that for you. You need to make the time to do it. It will save you (I say that deliberately – it may save YOU) in the long run.

Technorati Tags: Systems Management, Operations Management

Tags:   ESM · ITSM · Monitoring · Systems ManagementNo Comments.

Introduction
I have been aware of the Concept of a Software Factory for around 3 years or so. The Principle is very simple: If you are producing software, tool-up in order to produce good quality software that meets your requirements, at a very low marginal cost (cost of delivering one more business requirement) and in a very short marginal time (time to deliver one more business requirement).

Software is like a Car
Some cars have air-bags and navigation systems, but can be produced in the same factory as cars without either. Software Factories should be designed with the non-functional requirements in mind. If we consider the example of a car, the only real functional requirement is that it should transport people from A to B using public or private roads. Some of the definitions of what is considered a “car” constrain the designs (weight, number of axles etc). Other than these the remainder of a car’s features are in software terms considered non-functional requirements:

• Is it safe?
• What are its performance ratings?
• Convertible or fixed roof?
• Is it secure?
• Luxurious or Basic?
• Manual or Automatic?
• Spare Tyre or run-flat tyres with no-spare?

The Software equivalents should be fairly obvious:

• Redundant systems with fail-over capability
• Hardware requirements vs algorithmic efficiency
• User Interface for speed or ease of use
• Secure User Authentication and Authorisation methods
• Manual Installs or automatic updates
• Fat client or Thin client or both
• etc

Software is not like a Car
The Difference between Cars and Software is that potentially every piece of software has a different functional requirement, while pretty-much every car has the same functional requirement.

So in a car factory we can tool-up to produce homogeneous units with a uniform purpose, but with modular non-functional requirements that can be selected as options.

In a Software scenario the non-functional requirements remain modular and “optional” while the functional requirements have to be handcrafted or individually tooled.

So immediately the benefit of automating the numerous non-functional requirements for both software and cars is evident. There are several approaches to achieving this which will be discussed in “Software Factories: Part 2″

Standardized non-functionals are a prerequisite
The optimisation of the software coding process to ensure that non-functional requirements are not handcrafted or individually tooled is not sufficient. The greater organisation needs to accept the standardisation of these non-functional requirements before this becomes viable.

Once everyone accepts that tyres are made of rubber and filled with air, then the variables become size, durability, speed rating and aesthetics. If we cannot get everyone to accept the basic design of a tyre, our variables become infinitely more complex and we end up re-inventing the wheel with every new car design! (I know you saw that one coming).

Software is very similar in this respect. If the organisation can accept that the user interface for all web-based software looks the same and the user interface for all fat-client software looks the same, then I can derive benefit from tooling up to automate the creation of these.

An Ideal Example
I was involved in designing a software factory where all the software our company needed to produce was either form-based or generated a report. A standardized method for defining stored-procedures allowed us to automate the creation of the forms on-the-fly in the front-end and also automate the forms for inputting the report-parameters.

So the only handcrafting was the database design and the stored-procedures that interacted with the database. Everything else was written once, compiled once and deployed to everyone once. This fat-client included Authorisation and Authentication modules, data access and routing modules, presentation formatting, workflow calls, disaster recovery processes etc.

Now this was an ideal environment where we only had SQL databases and almost all software was internally developed.

BUT

We had the option of writing each discrete business requirement as a discrete and monolithic piece of custom code. We chose NOT to do that. We chose to design a software factory that allowed us to dramatically reduce the quantity of custom code written (which now only needed to support functional requirements) and we never again had to write any code to support non-functional requirements.

The time-to-market for each new business requirement was slashed, and we gained many other benefits as side-effects of this process.

So in each corporate environment where significant quantities of custom development takes place there will be some combination of non-functional requirements which can be automated to a greater or lesser extent to get the very real benefits of a Software Factory.

OK. Concept introduced! Next time we’ll talk about the various options for designing a Software Factory.

Technorati Tags: Software Factory, Development, Custom Code, Code Generation,

Tags: No Comments.

My post “Dismount!” last Friday (goodness it’s already almost a week ago!) left an open question about how you may have found yourself riding a dead horse (in the figurative sense).

Now in the context of this blog and on the topic of IT, a dead horse would most likely refer to a system that is either not being used, or is being used but is extremely unpopular within the organisation.

Very often these systems are not necessarily bad systems, but rather something has occurred that has effectively “killed” that system within a particular organisation.
So it may have died because:

• It is a bad system that has no business case and is not fit for purpose – (very unlikely)
• There is no buy-in from the users when the purchase decision is made – (fairly likely)
• There is no buy-in from the technical team who are required to support it – (extremely likely)
• It is too complicated and the users don’t understand it – (unlikely)
• It has not been properly implemented and is barely usable – (very likely)
• Key Stakeholders of this system change roles, and it is unpopular with, or unfamiliar to their successors – (quite likely)

These likelihoods are not based on any research, but are simply my personal opinions based on my experiences within a number of organisations.
Let’s unpack these and see how easily they can happen. If any of the following list of things occurs during a product evaluation or solution design process then we may end up with one of the situations above:

• A Vendor approaches senior managers directly and convinces them that the organisation needs this product, which then leads to …
• A manager bypasses the governance process to implement a particular product
• The Business Analysis is poor
• The Technical team implement the newest pet-technology, ignoring the business requirements
• The governance process for making purchase decisions is not aligned to business objectives or is in some other way broken
• When a key support person or Business Champion changes role and the succession plan does not exist or is poorly executed

Do any of these sound familiar? It is almost guaranteed that at some point, one or more of these will occur within any organisation, and this list is by no means complete.

The inconvenient truth is that it is seldom the product that is at fault. There are usually two basic processes that have failed in these situations:

• The IT Governance process around product decisions
• Succession planning

A sound IT Governance process will ensure that business requirements are met and that solutions align with business objectives and desired behaviours.
Good Succession planning will ensure that the healthy parts of the status-quo are not compromised during a change of “rider”

The bad news is that “when you discover you’re riding a dead horse, the best strategy is [still] to dismount”

The good news is that if you are careful about these two processes (IT Governance and Succession Planning) it is possible to keep a healthy stable of IT solutions.

The basic message is:

Don’t let healthy horses die
- Do pay attention to Succession Planning, and
Don’t buy dead horses
- Make sure Governance Mechanisms align with business needs and IT circumstances and then don’t bypass them

Technorati Tags: IT Governance, IT Management, Succession Planning

Tags: No Comments.