Tools strategy

 
 
 

Start

Access hints

Links

Forum

Business

Company

[Warehouse ] [Excel] [Access] [VB] [Citrix] [The client] [NT and SQL] [Internet] [Future]
 In our industry you must be focused and specialized into a rather narrow sector to guarantee your customers the skill you possess is updated and relevant. For the tasks we perform to our customers we have picked the tools we found most feasible for us to compete. The knowledge needed in these tools change over time so we keep a constant watch on what is happening and if needed upgrade our skills. In our choice we believe that both you and we needs a secure supplier, we have done it easy - all the tools we use comes from Microsoft. This also means that all the components that our solution uses probably already are installed in your computer.

Warehouse  
  Many call the system we develop ‘data warehouse’ but as with many buzz-word they have their own meaning of the term. We think we develop data warehouses, and with that we mean a system that is independent of the standard ERP-system with it’s own database that is filled with data from the ERP-system regularly (daily, weekly or monthly). Sometimes the system also includes some controlled information loop back to the ERP-system, could be budgets, forecasts, new item-prizes etc.

 Many times you hear the term OLAP when people talks about DW. OLAP is a special technique used to serve with fast response time for summary data aggregated over many records. This is done in a way that during off-hour the computer is put away of calculating a lot of sums that are used when querying the database. The technique of OLAP is rather complex and the effort needed to keep an OLAP-database up and in sync could often be a hassle. If you have many detail records and want fast response time you might not have any choice. Microsoft Office is today prepared so it could handle data from OLAP-sources. Many have the opinion that the DW should be complete and contain all information that is needed for analysis, that aspect together with the complexities of OLAP is the explanation why many people feel that the DW is out of their reach and to complex to understand when they have need for data. We think it is equally important that the data displayed is simple to comprehended, as it is that the tool used is easy and well understood by the user.

 Our customer and we often find that simple Office-solutions based on a smaller database and known tools serve much well than a fancy complex OLAP-solution. Often the solution fits to a smaller group of users in a department or in similar departments, but the good news is that it better fits into given tasks than a more general solution and that also why it will be more used and give the organization more business value. We believe in decentralized development of tool used in practice for personal effectiveness.

 In business today centralizing has less focus than earlier when companies are sold and bought in a pace never seen before. This means that self-sufficiency is needed in the smaller parts of a modern company. Last year you changed ERP-system based on last merger and in three years you are up to a new ERP-system again. The only chance to get business going is to have smaller systems you could use to solve your business problems in the meantime, else you will not survive.

 In the newer versions of Office Microsoft has fast gained great respect when it comes to decision support or what ever you call these systems aimed to put together information so you could base your business decisions on more facts and less feeling. In the last 2-3 years Microsoft has become one of the most important playes in the OLAP-arena, which was earlier dominated by a few smaller companies like Cognos. With the new functions around pivot tables Excel serves with many functions that are similar to those offered by special OLAP-tools like Powerbuilder and others. Many users feel more comfortable in the Excel-environment which is well known to them and Microsoft like many times earlier starts threatening its competitors. The pivot tables could be fed either directly from the ERP-system or by SQL-data or from OLAP-cubes.

 If the solution is offered in Excel the customisation could be done in VBA, which is a well-known language, instead of the specialized languages used in ordinary OLAP. The experts do the programs that gather the data into the right spots of Excel. The user could then use Excel to format their presentation of data either in tables or in graphs. With this approach you gain both simplicity and flexibility without huge investments in education. You get a used and spread system with great business value for fewer bucks. Simply we as IT-professionals collect the data you need and you format the information it in a way feasible for the task you want to solve either if you use Excel, Word or PowerPoint.

 To satisfy all needs around a data warehouse you will need a relational database. For many working in Windows SL Server is their natural choice and for people keen on Unix will probably Oracle be their choice. Both these systems offer integrated functions for a simple way of producing OLAP-cubes. Cubes are good in many ways, they give fast response time but they are a little bit awkward when it comes to flexibility and you can’t mess around in the dimensions in a way that you sometimes need. If you want a cube that allows a lot of messing around it will be huge and awkward to understand. In many cases more flexible solutions could be offered by the database in the data warehouse directly.

 By using standard products when building your data warehouse we could offer you a longer lifetime for your investment. You will also be better off to find know-how when you need modifications in the system since we base all our development efforts on VBA which is one of the best known programming languages available. The solution might not be as ‘sexy’ as what you will see on OLAP-demo’s, but where do you find these solutions in reality?

 If the solution is offered in Excel the customisation could be done in VBA, which is a well-known language, instead of the specialized languages used in ordinary OLAP. The experts do the programs that gather the data into the right spots of Excel. The user could then use Excel to format their presentation of data either in tables or in graphs. With this approach you gain both simplicity and flexibility without huge investments in education. You get a used and spread system with great business value for fewer bucks. Simply we as IT-professionals collect the data you need and you format the information it in a way feasible for the task you want to solve either if you use Excel, Word or PowerPoint.

 To satisfy all needs around a data warehouse you will need a relational database. For many working in Windows SL Server is their natural choice and for people keen on Unix will probably Oracle be their choice. Both these systems offer integrated functions for a simple way of producing OLAP-cubes. Cubes are good in many ways, they give fast response time but they are a little bit awkward when it comes to flexibility and you can’t mess around in the dimensions in a way that you sometimes need. If you want a cube that allows a lot of messing around it will be huge and awkward to understand. In many cases more flexible solutions could be offered by the database in the data warehouse directly.

 By using standard products when building your data warehouse we could offer you a longer lifetime for your investment. You will also be better off to find know-how when you need modifications in the system since we base all our development efforts on VBA which is one of the best known programming languages available. The solution might not be as ‘sexy’ as what you will see on OLAP-demo’s, but where do you find these solutions in reality?

Excel
  Earlier we used MS Access for the development of the user interface in our systems. Today Excel is in level with Access when it comes to the environment needed to do a professional job, so nowadays we often use Excel to construct the interface for the common user. Some of the maintenance tasks for the database are still easier done with MS Access so we keep them there. The advantage of this design is that it is much easier to get acceptance for the system in a wider group of people instead of having all to understand some of the specifics around Access. The other big advantage is that the user of the system has many more possibilities to do complementary jobs if the result remains in a spreadsheet.  

Access
With this tool we give you the opportunity to easily create any report you like with just a few clicks. We have developed a general query-function capable of constructing fairly complicated SQL so you could obtain the information in a way simple enough for you to understand. With Jet as the database behind Access is called it is possible to reach information stored in many different computers in your network, by means of ODBC and OLEDB as the technique is called. You could easily connect to data in Unix/Oracle, DB2/MVS, DB400/AS400, Dbase, Paradox and Excel in the same query. This function, which is very specific for Jet, is the explanation for this wonder. If the information is not directly reachable this way we easily construct the import function needed so you could work with a copy of the data inside an Access-file instead. 
 Would you like to change the layout or analyse it further we export it in a feasible way to your spreadsheet where you could easily add the final touch.

Visual Basic
  If your application has special needs these could almost always be handled by a complementary DLL (OCX, ActiveX..) that will could called from VBA. If that is not feasible in your case then this component could be done written in Visual Basic. Such solutions could be well integrated into an Office-solution.

The client(The Operating system in your computer) (Win 2000/XP)
  The solutions we offer needs a modern computer not older than two years with a 32-bit operating system (Win NT or newer). We have chosen this strategy since the prize of hardware now is at a level where it is very difficult to justify any time in software optimising. It is much cheaper for you to buy a modern computer than it is to buy a lot of time and effort from us squeezing in the solution into an old computer. The days of performance problems are gone…

Citrix, Terminal Server
  Today the technique of the ’remote desktop’ is getting more and more spread. It is a nice way of reducing the cost of ownership and gaining a better control of the standardized company computer. The methods we use are well gained in this environment either if you prefer Metaframe or Terminal Server.

Severn and the SQL-database
  Windows System is a cheap and effective alternative to Unix when putting up a server for a company or department. This is especially true when it comes to the skills needed to keep the server up running. We have chosen this to be our main platform for your database if you have need for a server based SQL solution. In Unix environment Oracle seems to be the preferred database. If you have experience in Oracle that is probably the best choice, if you are new to SQL databases Microsoft’s solution is probably the best alternative. Both products have good characteristics for serving a data warehouse and which is the best depend probably on your needs and what skills you have available in you organization.

Internet and intranet.
 
Some years ago this seemed to be equivalent with the future for IT. The focus on this technique solving all problems has finally ended and the discussion today is far more professional. We have not got a great focus but have working skills in ASP and IIS to keep our own Web-site up. We use FrontPage for the design of web pages and ASP for doing server scripting. When using databases in this environment we use OLEDB and ADO (JET and SQL Server) both for querying applications as for updating. We have invested some time in studying ASP.NET, but still not found any customer project where it has been feasible.

The future.
 
If you listen to Microsoft the answer is given: ’.NET’. This religion has many supporters outside Microsoft, at least among people trying to earn their living writing books about this technique. We do not believe Microsoft will give up this strategy, but we suspect that they as many others in the industry underestimate the costs of learning all developers keen on Windows these new tools. Nobody so far has been capable of convincing us that it is a hurry to go to .NET. The environment has a steep learning curve and since the goodies are rather few and not too useful at the moment we se no hurry. The basic shortcomings of the strategy is that Microsoft seems to believe that the same tool is feasible for all SW-development and that developers and users are willing to give up all earlier investments in solutions and know-how. These two factors guaranties that the adoption will be slow, very slow.

  We think the first to adopt is people working with ASP and WEB-applications since in this area the advantages are very clear. The investments in these area is though much smaller today than the where around the millennium which means that the breakthrough will be delayed, since investors are more careful these days.

  For people doing their development in C++ the advantages must be evident, but since this community is rather small and conservative the breakthrough will take some time. The two main obstacles is the feeling of loosing control and that the language has changed (C#).

  For people keen to VB6 the tool has suddenly becomes a lot more complicated. This will probably attract younger people without any earlier experience with much of pioneers in them. One of the most popular features of VB was that it totally hid all of the dirty plumbing in Windows. With .NET you now need to deal with most of these details. We believe it will be difficult to find purchasers willing to pay for the investment in new knowledge needed for people to do the change over.

  Looking at the last but probably biggest group of Windows-developers, the Office-developers, the change over has not started yet. With Office 2003 the possibility was given to call Office from .NET as well as do the programming in .NET instead of using VBA for Excel and Word. Any advantages of using this technique instead of VBA has not yet been seen, only a lot of restrictions not available in VBA, macro recording being one of hundreds.