Reinvigorate the Business Client – Extend your OBA over your Imagination
As I've promised, I'm starting to give a short description about my presentation, and will upload the demos.
Let's start with the presentation. On Tuesday afternoon I was showing to my audience, what does OBA mean, how can Office System and several LOB Systems be integrated in a transparent way, and what are best practices during OBA building. Yes, this process is a building process, because you can play with the OBA components as they would be LEGO blocks…
First of all, let's see the Line-of-Business (LOB) Systems. A LOB System is a software application or a suite of software applications that integrate the core data and processes of a business organization. Every company need its own LOB Systems. Depending on the company's type and size, these LOB systems can be really different. But as more LOB Systems you have, as more tasks you have as well:
- more administrative tasks
- maintenance issues
- scalability issues
- hard (or almost impossible) to develop and add new LOB Systems to a "spider-web" style architecture
- hard (or almost impossible) to develop and add new client components
If you want to have a systematized, ordered organization, you have to… first of all… you have to plan! You have to plan, if you want to survive, if you want to have a well-designed system architecture, if you want to be the first in your business market… Plan, plan, plan! You have to choose the good systems, solutions, the good platforms, the good interfaces, etc. Unfortunately there is no general answer, what is good for you, instead of this the planning is a really-really complex profession.
For example, imagine a company, where you have several LOB Systems: SQL Server, SQL Server Reporting Services (SSRS), Dynamics CRM, SAP, Oracle, etc. These systems live their own lives, but you want more: an integrated solution. In a few minutes we'll see why the MOSS is a good integration platform, but before let's see the most interesting LOB System: the SQL Server Data Services (SSDS)!
SSDS is the Microsoft's brand new data service – in the cloud. Remember: Software+Services…
SSDS means, your data is not stored in your own hosted storage. Your data is stored somewhere in the world, in a huge data center, and you can access them via several data access protocols – SOAP and REST. In this environment, you don’t have to waste your time and money to host a full environment; don’t have to worry about the performance, mainteinability, scalability, security, etc. To conclude: you can save a lot of time and money.
Well, let's see a simple SSDS example.
As you probably already know: SSDS is not a classical table-based database (with rows and columns), but entity-based. In my demo I'm using two simple types of entities: companies and users (employees). Both of them contains really simple data (address, e-mail, phone number, etc.), and of course, they don't have fix schema. For example, here are my companies:
1. SSDS companies on the custom admin page:
2. SSDS companies in the SSDS Explorer (my entities in XML):
3. SSDS companies in a MOSS site, imported by BDC (Business Data Catalog):
As you can see, the same data can be represented in a lot of ways (I'll show you one more example in the next part of this series).
In the following parts, I'm answering the question: when does it worth to integrate your system and when not. Why is it a good choice to build a MOSS based integrated environment? What is OBA and how you can use it in an integrated environment? For example, how you can build a MOSS and SSDS based OBA? What kind of tools you can use during planning, developing and deploying? Etc.
Stay tuned, next parts are coming soon!