Sober Counsel

Minutes of meetings have been around for a long time. Before email, they were circulated on paper to the attendees of the meeting. Nowdays they are circulated in a similar way, but the technology has changed - they are sent by email.

This has dealt with the following issues:

• Paper consumption has been reduced
• They can be easily forwarded to additional people

It has left the following problems though:

• minutes clog up email inboxes
• They remain difficult to find after a while
• they can only be seen and searched by the recipients of the minutes

Enter Web 2.0

If we use an intranet/extranet based blogging solution as a method of publishing minutes, then we can solve several more problems:

• Any person with access can search the minutes for mention of specific topics
• Tags categories can be applied and searched.
• Email box clutter reduced
• there is always a place I can go to refer to old minutes
• If I use an RSS-Reader I can carry historical, searchable minutes with me.
• It is easy to comment on minutes and distribute changes.
• Many blog solutions provide a subscribe-by-email module for those users who cannot adapt.

There are however certain issues:

• Security requirements of certain minutes will mean they have to be handled differently
• Version control of changes to Blog content is not very mature, or even desirable.
• Users will need to learn to use RSS-Readers.

For the most part, this will be a great solution to make it much easier to share and distribute minutes.

Tags:   Blog Technology · Blogging · Governance · Management · Meeting Minutes · RSS · Web 2.0No Comments.

In Formula 1 racing, monitoring and management are designed in from the beginning. All of the teams know they cannot be competitive without it and they are certain that they would not be competitive if they ignored the information provided by their monitoring systems.

In business we tend to leave the monitoring of systems as an afterthought, as a bolt-on at the end of a project, that we will do if we have some spare time. Very few business systems are designed with monitoring in mind, from the very beginning.

The operations benefit and business MIS benefit of having excellent monitoring only becomes apparent, once you have experienced it.

• The value of having all your business systems reporting client activities into your CRM system is only evident when you have an opportunity to impress an important client on your call-centre.
• The value of realtime transaction load monitoring is only evident when Christmastime loads start to hit your online transaction systems and you can see where your systems are starting to struggle.
• The value of detailed audit-logging is only evident when fraud has been committed using your online systems and you can report all the pertinent details to the police in minutes.

But it is costly to implement monitoring, because all of your code has to be modified and metrics thought through and added and the entire system tested and retested. A monitoring system can be added anytime, but the instrumentation that feeds the monitor has to be designed into your system. And it is significantly more costly to add instrumentation to a system after it is built than to have designed it in from the beginning.

Imagine again in Formula 1, if the team needed to add throttle position sensors to the car after it had been completely constructed. There probably wouldn’t be space to attach the sensors and no conduit for the wires, or sufficient processing power to record all the events or adequate bandwidth to transmit all the messages back to the pit. It will be a lot more costly to add all the necessary requirements after the car is built, than to have designed them in from the beginning. Just take one example - not enough space for the sensor. What do we do now?

• Change the design of the throttle assembly to make room?
• Buy the smallest sensor available and shave something to make room for it?
• redistribute the surrounding components so that there is room for the sensor?
• make the compartment larger and retest the aerodynamics in case they have to change as a result?

Wow! It would have been much cheaper to have designed it in from the beginning.

Ask yourself at the requirements stage of your next system:

• What do I need to measure to ensure that I have the right MIS once this thing is up and running?
• What do I need to manage in realtime when this system is running at its peak utilization.
• What information might I need to investigate failures or misuse of the system?

Don’t build it without a conscious knowledge of what it will cost to do now, versus what it will cost to add later.

Here is a copy of the Presentation used at the SPIN forum on 23rd August 2007:

F1 MITTUMAL Presentation

Tags:   ESM · ITSM · Monitoring · Systems Management1 Comment

We love our Children and we want them to grow up right, with good manners and appropriate attitudes towards the difficulties life will throw at them.

When they are young we make rules that they don’t necessarily understand but have to obey. It is best if they obey because they “want to” or because they love us. They could also obey because of the consequences of diobedience, but this is less optimal.

As they grow up we hope that they will realise that these behaviours are important and will be best for them in the end.

Projects are the same. Testing is important. Good design is important. The long term view is important. We can enforce adherence to these principles through consequences, but the very best reason for adherence is because the projects understand that it is best for them in the long-run.

So here’s the motive check:

Do you love your Parents?

• Projects, Are you behaving in the best interests of IT?
• Are you looking out for the good of IT?
• Do you wish good things and success for IT?
• Projects, do you love IT?

Do you love your children?

• IT, are you encouraging projects to behave right?
• Are your motives for doing this out of concern for the long-term success and good of that project?
• Remember these projects will always be your children, you can’t disown them
• IT, do you love your Projects?

Some children grow up being delinquent, but for the most part end up being good citizens who love their parents.

The motive is important. It is evident to children and they grow up to become different sorts of people, depending on whether they are loved or not.

Projects, are you the sort of children who end up being good citizens who look after their parents in their old age?

IT, are you the sort of parents who genuinely care for the long-term good of your children?

Tags:   IT Relationship · Lifecycle Management · ProjectsNo Comments.

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.