Archive for January, 2010

Try before you buy User Interfaces

January 26, 2010

Too many firms are failing to find a means to visualise their applications as early as possible, and those that do are having to throw away their “visualisations” so that the final application can be coded. If you want to produce usable applications, you must visualise early and create an iterative design process that evolves into the final coded application.

 Your team must recognise that usability and functionality work together hand-in-hand. Applications are often released to end-users without the necessary debate that could help shape a usable and useful application.

 The result is badly designed software that eventually needs to be expensively redesigned to suit user demands. It doesn’t have to be that way – and if users are consulted as early as possible in the visualisation stage, your business will have software that is fit and ready for purpose.

 Take a step back and think about your personal purchasing decisions. It would be anathema to buy a house by just looking at the specification sheet; you’d want to go the property, “walk the boards” and experience the space of the rooms and views from windows.

 Business applications are no different. Your end users need to see the application before it becomes final, to ensure it meets their stringent demands. Users, in short, need to try before they buy.

 One of the challenges is that screens that are dynamic (based on user input or data) require logic and the development of this logic can slow down the process. Hence the ability to “mock-up” data driven screens without having to program the integration logic required for that data should be a key requirements of the tools you select.

 Your users will be the people that interact with the technology on a daily basis, not your IT team. Your users will be the people that use the application to make crucial business decisions, not your IT team.

 The right tools will help you to dummy up and test your design (user experience) as part of the visualisation process. That way, you can complete an iterative screen development, without getting tied up in behind-the-scenes integration.

 Users will undoubtedly change their minds once they experience the technology; some will feel there’s too much on-screen data, while others will feel there isn’t enough information.

 Creating an early visualisation will overcome the majority of changes you would otherwise only get to hear about very late in the development cycle during testing.

Getting your application up as an early beta version allows people around the business to give feedback, without impacting on your development times and costs. And in a cost-constrained environment where users demands change quickly, early insight is bound to be priceless.


Decoupling the presentation layer

January 22, 2010

There is only one problem with finishing the job. When your work is complete and your software is integrated, it can sometimes be timely and expensive to modify your work.

 Just like in the case of a new home or car, great software meets the initial needs of the user. However, after initial use, requirements change and the flexibility and speed to change becomes very important. For example you wouldn’t want to have to rebuild a wall just to wallpaper it, or to have to change the engine of a car just because you added a body kit?

 Similarly in front end applications changing the “user experience” should have no impact to business logic/processes.

 The starting point is service-oriented architecture (SOA), an approach to software development that has quickly moved from the margins to the mainstream. Great SOA will allow the business to re-use existing components in new and exciting combinations.

 Here-in lays one of the problems of SOA, the majority of focus has been on creating “re-usable” services. Whilst this provides significant advantages we should not be complacent and lose sight of “layering” and more specifically “de-coupling layers”. Keeping the data source, separate from integration, separate from business logic separate from presentation provides much greater benefits that creating discrete re-usable services alone.

 Always think in a decoupled manner. Create as few dependencies between the application layers as possible. Such breaks will allow you to make changes and reduce the risk of defects further into the system..

 The most important focus should be the presentation layer. As the user interface, this is the layer that users will want changed most often, a bit like redecorating your home every few years.

 However many approaches to quickly creating front end applications require the use of bound controls, thereby creating a hard link between the front end and the underlying business logic. This hard link means that if you need to change the data source you have to change your front end screens to map to your new data source.

 A better separation would allow you to change a data source without affecting the screens at all.

 Decoupling the presentation layer – and holding information as a session variable – makes it easy to undertake alterations, loosening the tight reins between screen display and back-end coding.

 Whilst layering is very important to an application the decoupling of the presentation layer should be of paramount focus as the majority of changes will be in the front end and hence will require the greatest flexibility. This flexibility in the front end presentation therefore focus’s on the needs of the user. Which, in the end, is all that matters.


The contradiction of BPM…

January 12, 2010

For IT professionals, it is an important question: does service-oriented architecture (SOA) include business process management (BPM), or is BPM an architectural approach in its own right?

Many BPM vendors talk about SOA, suggesting a clear link between both strategies. SOA is an approach for making best use of existing resources in new and loosely coupled arrangements.

BPM, on the other hand, aims for continual improvement through the integration of technology. Proponents of both approaches stress the use of terms such as flexibility, innovation and optimisation.

In fact, some experts – such as research group Forrester (see further reading, below) – believe a new and combined category of SOA and BPM software products is emerging, a category that creates business process capabilities using the service-oriented approach. In my opinion, such characterisations are false.

Vendors might be keen to talk about the integration of SOA and BPM; they might also be keen to highlight how their product suites provide the benefits of service orientation and process control.

But what many vendors do not talk about is how using a specific BPM supplier can create tie-in. And what is service-oriented about a strategy that means you can’t pick and choose resources?

Remember that BPM is a product, rather than an approach. Choosing BPM creates an attachment to a number of specialist tools, many of which overlap with an SOA approach.

For roles management in BPM, which defines specific positions for people involved in the process chain, think of identity management in SOA, where rights can be modified flexibly in-line with changing project demands.

Integration is another area of concern. A BPM suite will help provide a workflow link between people, applications and services. Sounds good, but an enterprise service bus (ESB) abstraction layer will allow you to integrate components in a service-oriented fashion – without the tie-in often required by BPM platforms.

In BPM analytics are provided by a Business Activity Monitoring and in SOA this is the role of Business Intelligence tools. Whilst some BPM tools allow you to use third party rules engines (Business Rules Management Systems – BRMS), generally they will have their own.

Finally, most BPM implementations include a form builder that captures business data in a viewable form. In the case of SOA, firms can make use of an open presentation platform – like edgeConnect – that allows firms to create all their user interface requirementrs (e.g. Rich Internet, Portal, Offline, Accessible, Pure HTML and Mobile) not just basic HTML workflow screens.

So your choice is simple: take all the elements from a BPM specialist that might require you to stay wedded to a specific platform. Or aim for a service-oriented approach that allows you to pick required layers from a real specialist.

If you’re really aiming for flexibility and optimisation, the choice shouldn’t be too difficult.


Further reading,289142,sid26_gci1238154,00.html

Write once, present many times

January 12, 2010

More and more organisations, especially in Financial Services, looking to take existing products and deliver them to different brands, a business approach called “white-labelling”. For example LV provides car insurance through their own brand but also to a number of other brands like Nationwide and What Car.

 Whilst this isn’t a new concept, how this is being supported by IT is certainly changing. In the early days the product provider would simply take their existing pages, change the logo’s, phone number and possibly the font and background. Everything else, layout, question style, text etc… simply stayed exactly the same.

 However today it is the User Experience that differentiates an organisation on-line and is core to the branding. No longer is an online brand defined simply by logo, font and colours. Thus a “white-labelled” product has to be designed specific to the brands user experience.

 However this can present a challenge for IT, because in the old approach to white label a product you simply changed the style sheet and logo files for each brand, the form stayed the same. This way anytime a screen had to change it could be maintained for all brands with one change.

 So how do we get the flexibility to have different form layout, pagination, question order, question text i.e. a “custom user experience” per brand without duplicating form logic so that changes can still be maintained in once place?

 This problem is not solved through style sheets or by frameworks like MVC.

 The answer is not easy unless you take a tools based approach. Such an approach separates the form logic (what questions, validation etc..) from the form presentation (font, colour, text, layout etc…).

 A tools based approach is required to manage the link between the logical form and all the individual presentations of that form.

 This problem is actually not specific to white-labelling but to any screens that have to be presented in different ways e.g. to manage different views of a form for different: channels, user types, countries/languages.

 Financial services firms have already taken a lead in white labelling and multi-channel strategies; other sectors are likely to follow, branding applications for particular purposes. It is not difficult to see why the need to “write once present many times” will increase in importance.

 Modifying individual applications for different user experiences is an expensive (both time and money) approach in IT development. White labelling your products – as in the case of financial services – makes implementation cheaper and faster.

 Such capability increases flexibility and allows the IT team to write once and present many times. And with employees becoming more demanding, flexibility really is the biggest selling point for under pressure IT leaders.


Does CTO mean “career transition occurring”?

January 4, 2010

As IT professionals, we are not great at defining what we do and why we do it. In an attempt to show the importance of our work, we hide beneath a collection of buzz phrases and three letter acronyms.

Chief technology officer (CTO) could be seen as yet another layer of obfuscation. After all, according to online encyclopaedia Wikipedi, “there is currently no commonly-shared definition of a CTO’s responsibilities, apart from that of acting as the senior-most technologist in an organisation.”

So much for the definition, what of practice? Traditionally, CTOs oversee the technical staff that are involved in archietcture, design and development – but times, and role definitions, are changing.

Underneath the hyped up talk of agility, value and innovation, something real and tangible is happening. Businesses are finally waking up to the need to use and re-use technology resources in an open and integrated fashion.

Service-oriented architecture (SOA) – with its focus on component re-use in new and interesting combinations – provides a way for the business to stay alert in this new era of business technology.

In short, systems, software and services are becoming more specialised. By its inherent nature, SOA demands an integration of resources through a series of layers, such as operational systems, component-based developments, composite services, business processes and, finally, through to the presentation layer.

And to roll with this revolution, businesses must realise that the management of architecture is no longer a simple role for a single individual. Instead of managing a group of general architects, the CTO’s technology team – working to an SOA framework – should become more and more specialised.

Firms should ensure they have architects that focus simply on integration, process, presentation, security and business intelligence. Such layered leaders should monitor standards, vendors and open source offerings, creating a roadmap for their specific area.

Leading-edge finance firms are already undertaking such a transition and new roles – such as chief process architect and chief presentation architect – are beginning to emerge.

Fail to take a similarly deep appreciation and you risk your firm being left behind. So, what does CTO really stand for? In the service-oriented age and for the architects that serve the business, ‘career transition occurring’ would seem an appropriate tag.

Further reading