Office Business Applications is a term getting bandied about a fair bit these days.
What is it exactly? Well, answers differ, and you’d be forgiven if you thought it was as simple as using Office to build Applications for use in Business.
The purpose of this post is to try to get some simple high level understanding of OBAs. In later posts I’ll be digging into resources and also covering VSTO. (As per usual this is covered under my ‘well duh’ disclaimer.)
OBA - Concept
The concept behind OBA is perhaps best summed up in the following quote from the OBA Central site where they state:
“Office Business Applications are a new breed of application that… turn document-based processes into real applications.”
This sums up the main aim of OBAs: they are document based.
OBA - Delivery
But what about the delivery – the technology enabling it? This is where it can get overwhelming. OBAs can encompass a huge range of technologies. The Microsoft Office suite of course, but also (and perhaps predominantly) the Microsoft Servers with SharePoint Server being key, followed by Unified Communications (Office Communication Server), Exchange and Groove Servers. It also extends to non-Microsoft vendor products including SAP, PeopleSoft, even CAD programs.
Here’s how they fit together:
(Note: this is my own summary of OBA – based on an excellent Steve Fox webcast on OBA)
Line Of Business (LOB) applications
To really understand how OBA sits together we need to agree on what Line Of Business (LOB) applications are.
What are LOBs? Wikipedia is reasonably sparse on details but captures the main point: LOBs are related to business needs. SearchCIO has a more helpful description, highlighting that LOBs are vital to running an enterprise. That is, they are a set of processes/applications that run your business (or a division ie line of your business), and can be complex and deeply integrated with a number of systems. In terms of OBA they can be Microsoft provided (eg Dynamics) or other vendors (common examples are PeopleSoft, Oracle, SAP).
It can get blurry though – for example, why would Microsoft Dynamics be a LOB app and Exchange not? The distinction comes down to how they are used. If you just install one of the Dynamics apps and use as is to enhance a few processes then it’s probably not a LOB tool. But if you use it as a fundamental aspect of your business, to the extent that part of your enterprise relies on it, then it is a LOB app. Similarly, if you dramatically enhanced Exchange and built crucial business processes on top of it, then yes, it moves from being just a Server, to a LOB app.
When we talk about Oracle, PeopleSoft etc as a LOB app, we are talking about them being crucial to everyday business. Just installing an Oracle server somewhere in the IT department does not make it LOB…
Thus, summarising again the delivery aspect of OBA, here’s what we’ve got:
OBA = Microsoft Office + Microsoft Servers + LOBs
Digging deeper into the Microsoft Stack
This helpful diagram from the Office Business Applications Architecture Overview (well worth downloading – it’s a Word doc) helpfully puts it in context.
Looking through the diagram you’ll see that just about every facet of Microsoft’s Office, Server and Developer tool set offerings can be directed into an OBA scenario.
Admittedly this diagram is a little out of date (eg it refers to the previous version of VSTO, there’s no mention of Expression etc) but it does show the scope of OBA.
By the way, you’ll notice that most of the discussion around OBA is concentrated on Office 2007. What happened to Office 2003?
Whilst not specifically excluded (and in a later post I’ll be covering how Office 2003 is fully supported in VSTO) Microsoft’s push is definitely focused on Office 2007.To that end, just about every example, overview and case study features Office 2007.
OBA- Why?
Why is OBA so important?
The beauty of OBA (for me) is the way it brings together such a wide range of technologies, and aligns them for a common purpose. That purpose will be specific to each organisation of course, and by having a glance through the OBA cast studies site you’ll quickly appreciate how diverse and powerful they can be.
In terms of business benefit there’s plenty of compelling information about ROI and so forth on the OBA sites. But have your BS filters on, the figures that get bandied about are on the best case side at every turn, and sometimes are complete fantasy (marketing gets carried away for example when they try to make unrealistic licensing cost per person arguments). And whilst I agree that Office 2007 adoption is high (much higher than say Vista), we need to be careful when stating that OBAs provide significant training advantages because users are familiar with the Office interface. The fact is, to many enterprises the Office 2007 ribbon re-training is a hidden cost they can’t quantify.
But my intention here isn’t to nitpick, rather it’s to say that building OBAs isn’t an open and shut case when it comes to training cost.
To me the value of OBA development is in other key areas - surely the main benefit of OBA is the ability to:
- Use what you know
- Use what you have
Use what you know
There’s been cases where a new CIO joins an enterprise and successfully changes their entire infrastructure (eg comes in, chucks out Java and rolls out .NET, or vice versa). The reason these events happen is because the CIO knows they can get results simply because they have achieved success with those tools before, and they know how to manage the implementation.
This is extreme of course, but my point is that a particular technology choice is rarely right or wrong, rather its about whether you know how to make the technology choice work. The reason I mention this is because when it comes to OBA, many CIOs already know how to make two-thirds of the equation work (that is, they know Office, and they know Microsoft Servers). And this trickles down to all areas (users with Office, IT with SharePoint & Exchange, developers with .NET etc).
Summary: OBA may or may not be the best technology architecture – but it will often be the best choice – simply because your IT team know how to make it successful.
Use what you have
The second benefit of OBA is the ability to use what you have (ie minimise TCO). If you already have Office and Microsoft Servers in place, then building on top of them is a comfortable position to take. Notwithstanding the need to upgrade (eg Office 2003 to Office 2007, or SharePoint Server 2003 to MOSS) there is a considerable enterprise base in place that can be used. At this point the marketing collateral descends into ‘leverage’, ‘proven’, ‘scalable’ and other buzzword guff, but the point is valid.
Again, the actual technology may or may not be the best, but having it in place offsets costs required to develop functionality that might already exist in other offerings.
OBA- Who?
At this point you might be buying in to the whole OBA vision. But is it appropriate for your business? Does it apply for example, to companies with only 30 staff? Again the case study site provides good guidance here.
You’ll see for example that most examples are for large corporates (1000+ employees). But the good news is that OBA applies at all levels, and there are a few examples where companies with as few as 10 or 14 employees are using OBA to improve their business (the smaller company examples typically use Dynamics CRM as their LOB app).
In terms of where OBA is predominant, the top two industries are Finance (Banking, Insurance, etc) and Manufacturing and the top two processes are Financial processes and Sales processes.
OBA - Where does VSTO fit in?
Visual Studio Tools for Office (VSTO) is a small but vital part of the OBA discussion. It’s the main tool developers use to build the extensions to Office apps that allow interaction with LOBs. But that’s a whole topic on its own, and I’ll be covering that in a later post.
Summary
- Office Business Applications are solutions built using: Microsoft Office + Microsoft Servers (predominantly MOSS) + LOB apps
- They focus on automating document based processes.
- They are applicable to companies of all sizes, but usually enterprises with hundred or thousands of employees.
- OBAs allow companies to provide significant functionality by using What they know (Technical Knowledge) to utilise What they have (Technical Infrastructure)
- VSTO is a small but important part of the tooling that enables OBA
[If you found this useful you may be interested in other Clarity series posts]