Office Starter 2010

Office Starter 2010 may tempt some people away from the full paid-for version of Office and away from free alternatives such as OpenOffice.org.

I am a die hard user of free and open source software. I have been using OpenOffice.org exclusively for more than five years. I have written about how I would never turn back to proprietary software.

It has therefore come as a great shock to me to find myself increasingly using Office 2010, albeit only the free starter edition.

Office 2010 starter edition is preinstalled on many new Windows PCs, along with the means to upgrade to the full paid-for version. It serves two purposes. Its main purpose as far as Microsoft is concerned is to encourage people to purchase the full version of Office. It also serves as a replacement for Microsoft Works.

Office Starter 2010 includes only Word Starter and Excel Starter (so no Outlook or PowerPoint). They are surprisingly fully-featured, lacking only advanced features such as tracking changes in Word, and pivot tables and macros in Excel. They are free to use, and do not have a time limit. They do show adverts, typically for Microsoft Office, down in the bottom right.

Microsoft are careful in how they position Office Starter to resellers. They point out that Office 2010 is only likely to meet the full needs of some home users, not businesses or anyone used to the full office suites.

Why, then, have I started using them? Mostly it comes down to laziness.

Although we use OpenOffice.org internally, our customers and partners tend to use Microsoft Office. Although we can read and edit Microsoft Office documents in OpenOffice.org, out of laziness I had not changed file associations on my PC, and Word and Excel documents automatically open in Office Starter. However, Office Starter has the great advantage that I can save documents using the newer office formats (.docx and .xlsx), whereas OpenOffice.org can only write the old formats (.doc and .xls). This means that I am more confident that the changes and formatting that I make can be read again by others.

There are other things that tempt me to use Office 2010 Starter Edition rather than OpenOffice.org. It can now read and write the file formats used by OpenOffice.org and other suites (.odt and .ods files). Also, on Windows 7, my version of OpenOffice.org seems to have serious problems with pasting into other programs. This type of problem tends to get fixed quickly in open source programs, but for now I simply have to use Office 2010 Starter for some things because OpenOffice.org is broken.

So, by a combination of laziness, simplicity and desperation, I have started using Office 2010. I am even beginning to find my way around the new ribbon bar, which is initially daunting to anyone coming from other office suites.

I can not see myself rushing out to buy a full copy of Microsoft Office, and I do still use OpenOffice.org for most things. But Microsoft must have done something clever with Office Starter to tempt me away from my beloved open source software.

© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Self-destructing standards

Many standards suffer from creeping self-destruction. Should we do away with them?

There seems to be a common progression to the creation, elaboration and abandonment of standards. It goes something like this:

• Step 1. Someone has a good idea about how to do things differently.
• Step 2. Because the idea works well, they write it down for other people to use.
• Step 3. People think it such a good idea, they adopt it as a standard.
• Step 4. To make sure the standard delivers maximum value, it is made more comprehensive and more formal. An industry consortium or government body takes over the standard.
• Step 5. Because it is comprehensive and formal and official, people really believe in the standard, and demand it as basis for all work, even areas outside the scope of the original good idea.
• Step 6. An industry grows up around the standard, with tools, and training, and certification. People's jobs depend on the standard, and it is defended rigorously, and developed further and further.
• Step 7. The tools, training and certification take over; they become the standard; the original good idea is lost.
• Step 8. The standard is seen as bureaucratic and unhelpful, or just too hard.
• Step 9. Someone has a good idea about how to do things differently.

IT is particularly prone to this sort of self-destructive standardisation because people in IT are attracted to both making things systematic and making things efficient. The movement to agile methods is in part a reaction to the earlier structured methods, and yet we can not seem to resist adding formality which will eventually sink agile methods.

You can even see this happening with technical standards. XML is basically a simple standard for encoding data. People elaborate XML, with schemas, name spaces, SOAP wrappers, and things like that. In response, people adopt other standards, such as JavaScript Object Notation (JSON) structures, taking them back to something as simple as basic XML.

Although there are exceptions, where standardisation is both necessary and necessarily complex (such as HTML standards), there does seem to be a limit the sophistication and complexity of a standard before you get a counter-movement to something simpler.

I do not think we should get rid of standards, but we do need to avoid the problem of over-elaboration and abandonment. I suggest:

• If you have a good idea, try to distil and promote the fundamentals of the idea. Wrapping it up in a formal standard may smother it.
• Before you insist on a standard, ask yourself whether you really need the standard, or just the good ideas that it contains. If you insist on a standard, you might be institutionalising all sorts of baggage that you don't really want, and missing out on the fundamentals.
• Be suspicious of any standard where the specification runs into hundreds of pages, and where there are special tools and certification schemes. It will be hard work, and may be getting to the end of its life.
• Fundamentals are important. Standards can provide a good focus for the work, but they do not replace the underlying ideas and skills.

© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

SaaS and EAI 2: how to respond

To integrate software-as-a-service (SaaS) applications with internal applications, you need to think about integratability and control, not development speed.

Integratability, the underlying ease with which systems can be integrated, is fundamental, but we rarely think about it for in-house systems or demand it for packages. Integratability is achieved by having a defined, meaningful interface that opens up the functionality of the system to other systems. The technology is less important – it could be flat files, web services, or some sort of programming interface. What is important is that the interface is well defined and properly supported, and that it fully encapsulates the required processing, for example managing the rejection of invalid data.

When systems have good integratability, integration is hugely simplified. Basic integratability is the first step if you want to integrate your internal systems with SaaS.

Once these basic interfaces are in place, there are many options for connecting systems.

Personally, I tend towards hand-coding. I would define a common format and technology that represents the contract between two systems, and then write an additional layer of code at each system to bridge between this and the system's own interface. This approach protects your investment, because the impacts of changes to each end can be managed locally and do not have a knock-on effect.

Many organisations use specialist middleware tools and specialist teams for integration work. When considering the problem from an integration and middleware viewpoint, specialist tools and teams look like they give economies of scale and control.

I think there can be problems, though. We would not centralise, say, all user interface programming, because we know that the user interface is a fundamental part of the system that needs to be managed alongside the rest of the code.

Within an application team, economies of scale from centralised teams can mean project blocks when the work has to be scheduled. It can be easier to get your own team to write integration code in their normal development language, rather than to have to wait for a specialist team, even if the specialist team is more efficient. Centralising integration centralises control, but arguably it is better to align control with the business applications. Specialised tools add more components that need to be kept up-to-date, making it harder and more expensive to make your systems last longer.

The approach for integrating external systems, such as SaaS, is pretty much the same as internal systems. I would expect to develop a local proxy to convert the external system's interface into the common format used by the organisation. I have less of a problem with specialist tools for external systems, because there are fewer impacts to your organisation when the tool reaches the end of its life. However, it is still important to think of the common formats and underlying integratability of the applications to which the SaaS connects.

I know many are drawn to tools that promise to make integration easy. But in the long run, the easy option stores up problems as you take control away from the applications and become reliant on more components. Pushing integration effort to the applications looks harder, but is a much more stable option for the long term.

© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Saas and EAI 1: the problem

How will the move to software-as-a-service (SaaS) affect enterprise application integration (EAI)?

Subscribing to software-as-a-serice (SaaS) applications is all very well and good, but you still need to connect the software to your other applications, both those that you run in-house, and other SaaS.

This is a much harder problem that internal EAI. Internally, you can set standards for what data means, how it is formatted and how it is sent. Once you are dealing with external software, you have to fit in with what the SaaS provides. You have to maintain your automated and business processes across a much more heterogeneous set of technologies and providers. In the same way that architecture and governance become much more important, EAI becomes much more important too.

It is hard to know how to respond to this challenge. I specialised in EAI/systems integration for many years. There are some common traps that people fall into when doing EAI internally to the organisation, and it is worth considering how these might impact external EAI.

The biggest problem is that people set the wrong objectives for integration. Integration is of course about connecting systems. However, very importantly, it is also about preserving the separation between systems so that you have freedom of action in the future.

Given the technical challenges of connecting externally, many will fall into the trap of adopting the first method that they can get to work, without thinking through the long-term implications. This is of course even more important when part of the purpose of SaaS is to make it easier to adopt and swap software. Bad integration will quickly give you "legacy SaaS"; you do not want it, but you can not unpick it.

Another big problem is abdication. Integration looks hard, and purchasers will be tempted by SaaS providers who say they already provide interfaces into your other applications, both internal packages and other SaaS. In my experience these are never good. There is a lot of different between demonstrating that you can send simple data between two systems as a one-off exercise, and a long-term commitment to support your changing business processes across all combinations of versions of their software and those of another provider. Like it or not, you have to take charge.

There is also a big problem with tools. Well-designed integration is not that hard to implement. However, there are sometimes problems and it is useful to have a tool kit to solve them. The problem is that these tools then take over. People standardise on tools, rather than fitting tools around standards. All integration is then shoehorned into complicated architectures that problem connections need, rather than letting the majority of connections use something simpler. Inevitably you end up with a specialist team to support the tools, and knowledge of and accountability for the integration is split from those with direct knowledge of the business systems.

It is possible to avoid these problems, but it is challenging technically and is challenging to get management support because the right approach looks harder than the wrong approach. Next week I will outline what I think is an appropriate response to the challenges of EAI and SaaS.

© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Architecture and governance in an on-demand world

Over the next few years, organisations will increasingly adopt outsourcing and everything-as-a-service delivery models. We need to understand how to respond to these changes.

We need to start by considering the current approaches. At the risk of gross generalisation, current approaches to enterprise architecture (EA) and IT governance are detailed and standardised. EA involves formal models of business, covering business processes, organisational structure, information, business applications and supporting technology. IT governance involves controls on the change and service delivery processes used by the IT organisation. Both EA and IT governance assume a good deal of standardisation and maturity within the organisation.

Many organisations have problems adopting and getting value from EA and IT governance. Generalising again, many organisations view EA and IT governance as optional activities, that are only focussed on the IT organisation, and are disconnected from the realities of IT and of business.

It is tempting to think that outsourcing and everything-as-a-service will reduce our need for EA and IT governance, and sidestep these problems. It is certainly true that some aspects architecture and governance will diminish. If you run fewer in-house development projects, then you need less governance on your development processes. If you buy in software-as-a-service (SaaS), then you need less technical architecture. Overall, however, I think there will be a need for much more architecture and governance.

Take information architecture for example. When everything is in-house, using bespoke systems, the organisation's information architecture is implicit in the existing systems, and it can be hard to justify an architectural effort to formalise it. However, as soon as you adopt more packages and more software-as-a-service, you absolutely have to understand the relationship between the information assumed by these and your organisation's needs. The same is true for business processes. IT will be more heterogeneous, more dynamic, and less controlled, which makes architecture more relevant, not less.

Governance is similar. Where IT processes are all in-house, the case for IT governance is weaker because everyone involved is basically working towards the same goals. As soon as you introduce a service provider, there are potentially conflicting interests. The relationship, and every aspect of the service, has to be governed. IT processes will be less standardised, which makes governance more important, not less.

To respond to these new challenges, and to overcome existing problems, we need to change how we approach EA and IT governance.

I think we need to "get real", and to adopt a much more practical and down-to-earth approach. Current EA and IT governance are far too detailed, and their requirement for elegant models and defined processes places far too much of a burden on the organisation. We need simple, robust approaches that add value to the organisation even if its architecture and processes are heterogeneous and somewhat chaotic.

In this newsletter, I often write about taking a system view of IT, looking at IT as large lumps of business systems, rather than the whole complex of technology, processes and organisation. Simpler approaches like this are a good starting point for understanding architecture and IT governance in an on-demand world.

© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.