Tools in the ABAF toolbox.

The Abstract IT Business Application Framework (ABAF) comes with the following tools:

• Database importer
  This is a reverse engineering tool that lets you extract a database and translate it to table definitions in code. Using this tool will have you up and running with the framework in 15 minutes.
• Database manager
  This is the central tool to update your database. All necessary changes are applied to the database driven by the table definition model in your application.
• Schema visualizer
  A tool to show parts of your data model as an UML class diagram. It's important to note that this is the other way around compared to a traditional design and build process. Normally you would draw an UML model or an ERD model in a design tool. If the tool supports schema generation you can update the database and then start to make the necessary modifications to you application. In ABAF there is only one source: the table definition model in code. You will make the modifications only once and change the database using the database manager and visualize the data model using the schema visualizer.

This is an example UML schema for a small part of a dat model. On the top left there is info about the tables and fields, on the left below is an explanation what's kept in the selected table(s).

Because the model is kept in code you can also write to different output formats if you like.

Next time I'll tell more about the inner workings of the framework.

Introducing the Abstract IT Business Application Framework (ABAF)

Last time I've promised to unveil parts of the solution we are building at Abstract IT. Our framework consists of a complete base to build business applications in an abstractly defined way. The framework has been built with a few assumptions/principles in mind:

1. For every part of an application there is only one model.
2. Everything should be done in code as much as possible.
3. Every part of the framework should be extensible and replaceable.

Rationale behind the assumptions:

1. This boils down to the DRY (don't repeat yourself) principle. For example our framework only has one model for the data. This model drives the application but also the database itself meaning no separate manual task to create and change tables, column relations etc.
   
   
2. We try to avoid XML configuration files as much as possible, as they tend to have a life of their own. Somebody once said that every XML configuration file ends up as a programming language of its own, which you have will to learn first to be able to use it. Another reason is us believing that from a mental perspective its easier to stay in the same programming language and environment instead of switching between for example XML and SQL. Designers are also an example of this. They are great in getting things done quickly but they need a different mindset and in the end get in your way when trying to do something difficult. A third important reason is us wanting to have as much compile time checking as possible. This means that the vital parts of the framework, the models, are strong-typed. This helps in preventing mistakes and also aids the developer making the right choices at a given point by utilising intellisense. The last reason is that programming in an object oriented fashion is a good way to capture a model, because the model is still extensible and adaptable. If you put a model in some CASE tool for example, what do you think the odds are you can use the information in a different way? Most of the times you will only get what the tool offers. With models in classes you´ll always have the ability to extend or override behaviour.
   
   
3. We want to avoid vendor lock-in by giving users of the framework the ability to change and extend behaviour as they see fit.

In my next post I´ll talk about the tooling that comes with the framework.

Problems with software development nowadays part 3

In my previous post I ended by saying that defining only the 'what' of an application is very efficient in terms of size and thus maintenance. But are there any other advantages?


One other advantage I can think of is the ability to change implementation. An abstractly defined application can in theory be executed on every platform, every operating system, every user interface technology, as long as somebody provides an runtime implementation. This is actually a way to fight technological decay (see part 1)


Another benefit of abstract definition is it can help with attaining a noble goal: don't repeat yourself. The don't repeat yourself principle is well known in software engineering but rarely reached. Take a simple validation rule like: the country name field in the country table must be unique. You want to define this rule only once in your application. You want the rule to be checked at least in two tiers: in the client before saving a new country record with feedback in the UI when the rule fails and in the database by using a unique index or a trigger. One can think of these as two implementations of the same rule. Business applications are filled with this kind of validation rules, simple and complex. It is a very common pattern in business apps. In current development you will have to implement the same rules twice, mainly because they are expressed in different languages, like C# and SQL. This introduces all kinds of problems. How to keep both implementations in sync? How to be sure both rules check the same thing? Often the rule is only implemented once leading to problems with dataconsistency when the check is only implemented in the client tier or incomprehensible feedback when the checks is only implemented in the database.


Yet another benefit of abstract definition is standardisation. Standisation in the way an application behaves and looks. This is because when abstracting a business application you try to generalize components of the app, striving for generic solutions instead of specific ones.


In my first post I talked about how to keep documentation up-to-date? I think that we should make documentation part of the development process. On various development platforms this is already partly done for technical documentation by documenting classes, properties and methods. So why not for more functional information? Documentation should be like creating classes. That way it stands a better chance of being adapted and maintained while changing code. The documentation can then be extracted from the application and can be presented in various forms like Word, Visio or whatever format is desireable.


Today I've tried to show some big benefits of defining a business application abstractly. The big question remaining is how to do that? In my next post I'll reveal parts of the solution we are building at Abstract IT.

Problems with software development nowadays part 2

So how can we fight these 'decays'? Obviously we cannot really fight functional changes. Businesses change, people change, requirements change. This is one of the big constants if not the only constant in software development. Probably one of the best things we can do is to keep the system in such a state that functional changes are easy to apply. This translates to: keeping the system modular, low coupling and high cohesion, keeping the software as simple as possible, well documented etc. Normally the bigger the system is, the harder it is to make changes. So keeping the program as small as possible is also a very good thing. But how to do that?


The second point of my previous post concerns the loss of knowledge. How to keep all the knowledge at hand and up to date? In practice it is very difficult to keep the code and the requirements in sync. Is there an easy way to keep them both up to date?


The third point is about technology changes. We can develop a system in JAVA or C# or some other modern language but maybe in a few years time there will be a new language lets say X# that everybody loves to use for programming. When time passes fewer C# programmers will be available to maintain the system. In the end we actually call those systems 'legacy'. Think about how many COBOL programs are still running businesses every day in the world? There was a time COBOL was 'hot'. This can also happen with current 'hot' programming languages.


The third point is not only about programming languages it's also about smaller changes like new UI technologies, different hardware platforms or different operating systems. Over the last 5 years we've seen a lot of changes regarding user interface development for example. We have seen ASP.NET with AJAX, JQuery, Richfaces, RIA's like Flex and Silverlight to name a few. It's not easy to change a system from one technology to the other. But you have to make a decision to build a system in one of these technologies if you start building it today. You can of course develop the system for multiple platforms but that would surely mean a lot of duplicate work. Can we be sure today that silverlight or any other technology will still be supported in 10 year time? It's seems to me that big and complex business applications have a bigger or should have a bigger lifespan than those technologies. Maybe the business application should be independent of them?


So how to make a program as small as possible, documentation and code in sync and applications independent of technologies and platforms?


One way to make a program as small as possible would definitely be to only specify what the business application should do and not how. Think about it: only specifying what an application should do is about as efficient one can get. You cannot solve the problem with less information!


In my next post I'll elaborate more about this topic and the solution I envision.

Problems with software development nowadays part 1

Building custom-built software for a complex business scenario is a big, expensive and risky endeavour. This has many causes. Getting good and complete functional requirements being the most important one of them. Also question like which architecture should we use, should we develop our own components or buy third-party components, have to be answered before starting development. These choices are fundamentally important. They to a  high extent determine the lifespan of the system.
Once the system is ready it needs to be maintained. At that point every system is susceptible to various forms of decay:

1. Functional decay
   No system is static. There are always new wishes on the horizon and sometimes existing functionality in no longer needed. The bigger a system gets, the more difficult it becomes to change fundamental choices. I call this the law of the oppressive scale.
2. Knowledge decay
   People come and people go. Often resources who did the original design and implementation have left the team. Has the knowledge about the system been spread over other developers and designers? Is there any documentation and is the documentation up  to date?
3. Technology decay
   Also technologies come and go. Software engineering is a field in motion. About every 10-15 years there has been some kind of paradigm shift in software development: from procedural to OO, from OO to functional, towards DSL 's to mention a few. Normally a system is built in a technology that is 'hot' at the moment the decision is made to implement a new system but who says that technology is still hot in 10 years time? I think it's a waste of time and money to rebuild a system, just because of a new technology.

So how must we advance in software engineering to fight those decays? This will be the topic of my next blog.