Walter Almeida's Blog

Introducing my favorite ORM tool: Llblgen

In a previous post I introduced the concept of ORM tools and their high importance in software development projects. Today I want to talk quickly about my favourite ORM tool: LlblgenPro, and explain why it has been one of the best tool I have had the chance to use for quite a long time.

 

Have you ever been really amazed by reading the marketing material for a product and think: hey this is what I need! Looks like it's doing everything I want/need plus even more things I would not have thought of first, let's get it!

You would then go and download the trial, with the grand hope that you will be simply satisfied, and not once more disappointed by an advertising façade, selling why the product is the best of the world.

So here you are, trial downloaded, and first eliminatory test is how easy or hard the product is to install and first use. Once the first, supposed easy test is pass, then you start using the product. If you are lucky, the first tries are satisfactory and you still find the product very attractive and are ready to go and celebrate this with your friends. If you are really that lucky and don't live in the real world, you never discover any problem with your newly purchase product and live happily ever after.

However sad but true, more common scenario is that you discover one by one, sooner or later, the flaws and problems and bugs that goes with the product. And interestingly or not, this was not sold on the advert. But the thing is that it comes in a bundle: you get the great stuff and the bugs and problems all in one for the same price, how great is that?!

Unfortunately this happens quite a lot, it is very common to have to make compromises and use a tool because it has great features and you need it, accepting all the bugs, design and functional flaws, perhaps lack of flexibility that come with it. Well you still can contact this great support team: they say that they are available to solve your problems, so wanna call them? Ok right: one doesn't loose anything to try, except perhaps patience and hair…

Ok all is not so bad. You have products to absolutely avoid, and products that are better and being a pleasure to use despite of some drawbacks. And you have few tools that are absolutely phenomenal, and Llblgen Pro is IMHO one of these.

I have already used Llblgen Pro on several big size projects for several of my clients. For information I am always using the adapter flavour of the templates and runtime as I am working on large distributed tiered-architectures and need the disconnected pattern for communicating between tiers, throw web services.

So I must say I keep enjoying the fact that I really love this product, and cannot find anything significant to complain about, which is very uncommon. And Frans, where are the bugs? Pretty very well hidden I must say, was looking for them but apparently didn't get any luck: I find the generated code and runtime extremely stable and robust.

Ok what else can I say? Well, installing the product is very easy and nothing to report, using the designer is pretty straightforward too, and using the generated code made very easy too: the generated projects are including all the proper references, are compiling perfectly fine, and you then just need to reference the generated project and runtime support libraries to be ready to map to your relational data in a full object oriented way.

Even more important: re-generating your projects after changes to the database, on existing entities or creating new one is extremely stable and pain-free too. May you add items to your projects, add your custom code, all is re-generated taking very good care of the work you have done before.

Ok you will tell me that changing the database has impacts on all your code, not just you data access and business entities layers. Well, ok, but don't forget we live in a full strongly typed object oriented code now. So may you have broken your code after update of the database and regeneration of the business entities layer, well, you will know it at compilation time and fix it very quickly!

Another very important point for me is the quality of the generated code and of the runtime source code. For such a technical tool one expect very high quality of the code base, and you get it with Lllblgen. When using the generated code or runtime libraries, you never get the impression of a poor design or dirty kind of object oriented, having design inconsistency or suspicious quality issues. No, this is only great clean object oriented code, handsomely designed, I just LOVE IT

What else can I say? Well the development efforts are pretty well sustain in that Llblgen Pro keeps constantly up to date with the newest versions of Microsoft .NET framework when they get shipped. And much better than this I must say: Llblgen Pro really makes the most of new features of the .NET Framework very fast. Example is the very early support of Link (though Link to Llblgen) and Dynamic Data.

Another point is the extra features that are provided out of the box for you, for free. Examples are support for auditing, and security (authorizations). So you have access to points of extensibility for your application just by using the tool. Let's see what new exciting features we get in the future.

What else? Oh yes, support. Llblgen Pro has got the most amazing support service through its forums. You get answers extremely fast to your problems and issues and bug fixes integrated quite fast in subsequent releases. And it is working, they really are there to help you, it is not only sugar to make you buy the product!

I see one bad thing though about the tool…. And it is its name!! Just still haven't really managed to adopt it J Well who cares would you tell me?

Just one thing to be aware of: I am telling a lot of great thing about Llblgen Pro, just be aware that you will have to go through a learning curve before smoothly master the framework. However it is the same with any framework and believe me: it really is worth it. And with the addition of Link to Llblgen, developers knowing Link will have their opportunity to leverage their knowledge and shorten the time needed to master the tool.

Ok enough for now, you can just go to their website to get more information on the tool. And I will write more posts on scenarios in which I am using Llblgen Pro. So go, and try it! And NO, I don't have any shares on the product, just like to tell when there is a tool that deserve attention. And I will dedicate a section in this blog, dedicated to registering interesting and useful tools and framework, as it is one part of the whole "Building Business Oriented Software Solutions" concept.

You can also read my post about Object Relational Mapping (ORM) overview

I have a Dream, an Ambition, a Destination and Faith

I tried today to search for myself on the cloud, trying to "google" keywords and hey! I can find myself, much better than a week ago! I realized that I start to gain visibility, yet not having many visits, but surely getting more and more visible globally. And I must say it is a great satisfaction and I realized something is happening, that the seeds I had been throwing for so long are growing now. And this is why I felt like writing today's post, as a summary of the evolution of my thoughts and feeling during the last many years.

   

I had a Dream….

I had a dream, a dream of a harmonious life, a harmonious world. A world where you get what you truly deserve, where you safely and openly receive and give equally to your surroundings. And I had the even more beautiful dream that this harmonious and positive environment could be complete and extend through personal, professional and social life; and that the business world could seamlessly be part of the host environment for such good and true things.

I had the dream that profitable business and success can be achieved with respect of humanity, justice and be achieved in a positive, loyal and genuine collaboration with the surrounding world. I had the dream that a business can be not only driven by return on investment but also be based on deeper principles, with the aim to achieve a higher goal, born from the mind of the creators and shared by the whole company as the driving force.

   

I experienced Deception…

I experienced deception; saw dark sides of the real world, witnessing conflicts of power, worth: been part of some, seeing corruption, understanding the sadness and negativity of extreme individualism, ignorance of others, disengagement of good principles for the sake of un-deserved, dirty success.  

I experienced deception, for having given 200% of myself for companies that did not deserve so much, at least not so much from me as I was wrong in my beliefs of what they really were. 

I started to give up and felt forced to slowly engrave in my soul this so often heard hurting sentences: "That's life, there is nothing you can do about it, you should stop dreaming, you should be adult and accept reality and live in the real world…"

Resignation was eating me from inside, driving me sad and empty. However there was still this little spark of hope in the depth of my heart, this great positive energy but made miniscule by the impact of experiencing life and uncontrolled interaction with the outer world. Sad but still dreaming from time to time, I woke up one day: HEY !! I AND ONLY I decide what my reality is, I decide if I want to keep dreaming, if I want to make my dreams my own reality!

    

I had an ambition…

I can say nothing but thank this little spark, my guardian angel to have always kept me alive, pushing me to fight, stand for my beliefs, for my dreams, despite of any negative signal that the dark sides of the outer world could send me. So "that's life? There's nothing I can do about it??"… No indeed there is nothing I can do to change the big size company I am working for, if I don't believe what they are doing is right. No Indeed I can't change my so called friends if I believe there are not worth it and don't follow the same principle as I do. But YES I definitively CAN stop complaining, stop being negative, and I CAN choose the company I am working for, I CAN choose my lover and my friends, and I CAN be proactive, and do whatever I am supposed to do to go for what I believe, I CAN choose my life.

My choice was to create my own company. I always have had my vision about how a business should be run, how I would like to build a trust and win-win relation with the members and partners of the company, what good principles should be applied. Yes I knew that I had not a business educational background and that very experienced business owners could just laugh at my words. But still I had my vision and my choice was to implement it, learn by doing and challenge my own beliefs. And I am very experienced myself in my own beliefs; ideas don't make it all, but work and courage just do the rest.

I had the ambition to create a company the way I imagined it, the ambition to prove to the others and first to myself that YES, I can dream and yes I can make my dreams my reality. I knew there was a path to achieve this journey: courage, faith and hard work. I also knew that the path would be long and difficult, but that it would be worth it, and that no big fulfillment can be achieved with no significant challenge and full dedication. 

   

I have a Dream, an Ambition, a Destination, and I have Faith!

Today I have a dream, an ambition, a destination and faith. I simply don't give importance to my deceptions apart from learning how to avoid them as much as possible and how to accept them when they happen to quickly let them fade out.

Today nobody will take me out of my path and my beliefs, a process has started and I have a destination: go for my beliefs and build a company the way I imagine it, the way I dream it. I want to build a company that is truly different, a company where every member will be part of the success, appreciated for his/her skills, courage, and personality. I want to do business a different way, driven by honesty, justice, merit and true human relationship, in the best shared interest of all participants, be they internal or external to the company. I want to go beyond regular business and build it with the same driving principles that I apply to my own personal life. This is my ambition, my destination, my life; faith, positivity and support of my loved ones will be my energy to do it.

Event based architecture and test driven development

I listened today an interesting podcast related to event based systems and one aspect especially caught my attention: how an event based architecture is a good cadidate for test driven development.

You can find this podcast on DotNetRocks: "Ted Faison takes events to the limit" and the speaker is Ted Faison.

So first interesting point is the difference Ted makes between events based architectures and event driven architectures. Ted describes event driven applications as applications that react to events and therefore whose inputs are events but events are not necessarily used as a core design element of the application. With no events fired, event driven applications are just idle. On the other hand event based applications are applications that are architected and designed with events as a core technique to inter-connect application components. Events in event based architectures are really a first class citizen, design element of the system.

An interesting point is that in a properly designed event based architecture, the inner components of a system are loosely coupled, and you can even imagine changing connexion between components, either statically through configuration, or dynamically at runtime. And high level loss coupling in software architecture is definitely a high goal to aim at.

To design an event based applications, and enforce the components lose coupling and ability to map and inter-connect components in a configurable way, well approved patterns exists to do that, so an event based applications will most probably integrate patterns like builders, binders and coordinators. For instance, to achieve the highest level of loose coupling, neither the receiver of the event nor the emitter of the event should know of each other; and to achieve that, a binder component would have the responsibility to wire and connect the components.

So here we come to the very interesting part of Ted's talk: event based architectures are by essence well suited to test driven applications due to the lose coupling aspect they promote: you can imagine testing single components of your applications without having to bring up the whole application including databases, web context and all expensive or difficult to test resources. And to not bring the whole application up, the only thing you have to do is to simply not connect the components; or to connect to mock up components instead for testing purposes.

And it is commonly understood and approved now that TDD development is a very good practice to build robust, maintainable and flexible systems, even though quite often proving to be a big challenge. Go event based and you have a good starting point! I am personally using dependency injection patterns to build the loose coupled application architectures + dynamic mocking framework for test driven development (more on this on other posts). Event based architecture is another interesting strategy to achieve the same, while having its own advantages and draw-backs. So up to you to decide on one, or maybe any other alternative!

So as a conclusion, I must say that Ted Faison's podcast was very compelling and convincing and an enjoyable listening session, presenting a deep look on amazing possibilities open by using events! It could worth having a look at Ted's book now: Events based programming: Taking events to the limit.

REST Versus Web Services

Okay, I had been hearing a lot about REST lately, not really knowing what it was. Seemed like standard web stuff for me, lots of talks about HTTP verbs, post and get and that kind of things. So I wonder was what was new in the whole idea? I therefore decided to educate myself a bit and started with listening to this podcast of Software Engineering Radio: Stephen Tilkov on REST

So indeed there is a lot about just standard, existing web standards in REST, and this is what somehow makes it powerful. The new idea is to use standard web techniques to perform inter-communications between systems, in a SOA fashion. I won't enter into technical details and explanation on how REST works, first of all because I am not an expert at all and secondly because there is already plenty of documentation out there on the cloud. I would advise you listen to the podcast for a start if you are completely new on the subject. And good thing about this podcast is that the speaker is coming from the web services world and moved later to REST, he therefore has a good idea of the differences and pro and cons of both techniques.

 

My intent in this post is to try to analyze what REST means, where it apparently fits in the web and SOA world and what may o may not the proper scenarios to use it. I will do that in a very humble way, dropping my first thoughts on the matter. I may be missing important points and be inaccurate on some others so all comments are very much welcomed!

 

At first REST appears like a simplification of web services, SOAP and WSDL technologies to remotely connect systems in a system implementation technology independent fashion; there is obviously a technology common point in it and that's happening at the transport and protocol level, but internal technology used to implement the communicating systems can be anything as long as it is providing REST end points. I remember when in the past I was using DCOM to connect systems, thinking that such component technologies like DCOM or CORBA where the proper way to make distributed systems communicate and the de-facto standard (or multiple-standards I must say as they are not technology agnostics). I remembered then when I first heard about web services and SOAP and thought: hey what's that!! we have great, complex technologies like DCOM or similar (by the way I Loved COM...) to interconnect systems, so how can a simple kind of loose coupled messaging system could possibly do the trick instead and efficiently connect my systems?? Well today in state of the art architectures, inter-applications communication is (in most cases) handled through web services, at least for communication outside of the company, or between systems that need to be kept independents and probably implemented with different technologies or by different teams. So will REST become the new standard the same way web services did in the past years?

My understanding of REST is that it's mainly useful for CRUD like operations, even though you can add support for more custom verbs than the standard HTTP verbs (but then you lose part of the advantage of seamless and full integration on the web that you would have by using only standard web and http technology). The main purpose of REST is to see business entities as web resources and access them the same way you would access a web page or an image or any other resource through HTTP. Great thing about the idea is that there is nothing new except! If you know how to get an Http resource through its URL, you know how to get a customer entity through REST, isn't that great? It means that interconnecting applications could prove dramatically easy. However if you need a "real" business service that does more than just CRUD operations, then you better off, IMHO, keeping working with classical web services, WSDL and SOAP over HTTP (or other transport layer BTW). To summarize, my understanding is that for enterprise level, business applications, classical Web Services could still in many cases remain the best choice. Another scenario is the need for advanced enterprise wide services like security, confidentiality, transaction (even though transactions on the web has to be taking with care, we should rather be talking of compensation systems), asynchronous processing, then classical services will have much more to provide with the WS* implementations.

Another point to note with REST is that the communication is quite "relaxed". There is no notion of strong data type as there is with WSDL contracts. Therefore it's up to the client to know about the data that is received. If you need extra expressivity for your service then REST might not be the best choice. Well one can argue than REST can get business entities in an XML format, so you can add expressivity through schemas. Other issues I can foresee: how do you handle versioning of your services with REST? How do handle service location and service directories? Well there are many aspects to cover and would require more writing (and more investigation!) and will not be covered in this quick overview.

On the other side, for web facing services, REST will be a great solution: after all, most of the mashup web scenarios are using CRUD operations, and not even CRUD operation but simple read operations in many cases. REST is then much easier to use to mash up services than going through web services which need proxies to be accessed, and specific knowledge of SOAP and WSDL. And for what security is concerned, forget about all WS* specification: just use standard web security protocols, making interconnecting systems on the web in a secured way much easier and accessible to more people.

Well that was just my basic vision after first a first go through REST talks here and there, let's see in the future what comes up!

Oh, another wonder I had: hey! we're having this new, exciting feature of Microsoft.NET framework called WCF and it is all about connecting systems in a (as far as possible...) technology, protocol and transport independent way. So what about REST versus WCF?? Well good news is that WCF now allows to expose services through REST and consume REST services, so this is just a great thing, because one can invest on WCF without having to wonder if REST and a REST implementation would be a better choice: no worries: it's part of WCF through the new WebHttpBinding! So let's see how easy it is to build a WCF service, expose it through SOAP and with simple configuration change, expose it through REST. Haven't tried yet but should be pretty straightforward! We can see with this specific case an example of how powerful and extensible is WCF!

 

While we are talking about Microsoft and Microsoft technologies, I guess that REST will be interesting for Microsoft in many scenarios, let's see what they do and if they use REST for interconnecting their various systems. For instance we can already see coming the generalization of the use of the Entity Framework and especially the EDM (Entity Data Model) aspect for interconnecting Microsoft systems and exchanging data (more on another post). So REST would be a way to exchange the EDM entities across systems like Astoria Data services, Velocity, SharePoint and much more… And I was telling that REST seemed a good candidate for CRUD operations; well velocity and Astoria are all about exchanging data in a CRUD fashion, aren´t they? So let´s see how all will be consolidated in the future!

That´s it for this first overview of REST versus Web Services.

Golden Rule #1 - Don't write code!

The software development golden rule number 1 is: don't write code. Well… seems quite inappropriate to say that about a software development project! The title is a bit exaggerated and the idea behind this golden rule is that you should code only what's mandatory and linked to your business and limit the lines of code to the minimum.

The less code you write, the less time you will spend in writing code (obvious), the fewer bugs you will write, the less code you will have to document, maintain and make evolve. And the less code you will have to refactor sooner or later. This refactoring aspect is quite important and will be the object of another rule stating that any good quality code or software architecture has to go through many refactoring cycles during its lifetime.    

So here are some advices to drive you to limit the code you will have to write:

1. Develop simple solutions. The simpler, the better (another golden rule BTW) and the less code is required. Obvious isn't it? However creating simple solutions IS a challenge. How many times have you been in the situation where you're asking yourself: hey that was obvious, how didn't I think about it in the first place? Thing is that as developers we have complex minds and are looking for the most amazing solutions, and it can become over killing and drives us to developing over-engineering solutions. Good practice is to always try to think twice on a solution and wonder if it could be made simpler. Do peer to peer code reviews with simplicity as one of the goal, presenting your work to others and having your solution challenged is a very good way to enhance and simplify your design

        

2. Linked to previous point is: always develop minimal solutions, answering a direct functional need. As passionate developers we often tend to do too much for the sake of building great applications. Yes you need to design and develop with evolutivity in mind, but wait for the functional requirements before make your design evolve and implementing more that necessary. In the mean time you can concentrate on building simpler, bug free applications and spend the remaining time to develop the unit testing code. And don't worry: new requirements will come and you will have the opportunity to express your creativity on something really required and useful, so be patient!

        

3. Reuse existing components (or frameworks) whenever possible and whenever they are not a company asset or directly linked to the business you are working for. There reusable components can open source components, third party out of the shelf components or your own components. One of the most obvious examples is the use of a GUI framework. You don't want to write a new grid component unless you have a very specific need or unless your business is to build GUI components. What you will have to care of though, is to make sure you choose stable, good quality and well supported components. So spend some time in selecting them and then reuse them in all projects where their use makes sense. Other obvious components to use are those which are related to technical, transverse concerns such as logging, dependency injection, data access and much more...

        

4. One layer of abstraction above components is the use of existing applications or server applications. For instance (almost) no-one will develop his own operating system, or relational database system. These are obvious examples, however an apparently not so obvious one is reporting and you can see companies developing their own reporting layer where one could leverage an existing reporting solution. In the Microsoft world this is Reporting Services, part of the SQL Server services. Another example of an out of the shelf application server is Microsoft SharePoint Server, full electronic document management, collaboration, publishing (and much more) application, fully integrated with the full Microsoft application suite, especially Microsoft Office. Of course there can be a licensing price to pay, but usually the benefit and return on investment is far beyond the licenses you will have to pay, providing that… you choose the right tool for your need! So same story than for components: you should carefully take time to evaluate and choose the right set of applications for your need! But when that's done the gain is then huge.

     

So as a developer you should focus more on evaluating and choosing components, frameworks and applications (unless you're working in a big team and have an architecture group doing it for you, but then try to understand the choices that were done) and compose and integrate them that coding everything from the ground up. You obviously still have to write code but at another level and directly linked to your business. And it will be for you a first step toward a larger vision of software system and toward the software architect role. This also help keeping a good separation of concern in your application design (another golden rule, hey! we are starting to see a common link between all this and it probably confirm the more I will be writing on the subject!)   

So that's enough for now and hope to have caught you attention and you will join me for later post on other golden rules!!

The Golden rules of Software Development series

Last night I thought about an idea for a "post series". I often have coming to my mind quick thoughts about short tips and best practices related to software development. Nothing big, just some general thoughts that could be used as the "tip of day" kind of scenario. I have the tendency to think a lot and the best way for me to release this energy and free my mind is to write down my thoughts and share them. 

 

Good thing about writing down your thoughts and ideas and sharing them is that it forces you to formalize them which often is a more difficult task than first thought but prove to be a very creative activity. I indeed fell and realize that writing down and sharing my own thoughts uses and converts simple, volatile brain energy to fully constructed and usable ideas, and concepts and therefore leverage their power.

 

So I decided upon starting today a series of post called "The golden rules of software development". It will be a series of short posts, about general software development best practices, in random order. First post will for instance be titled "Software Development Golden Rule #1 : Don't write code!"

 

Hope you enjoy the reading and please feel free to comment and react on them!

 

Click here for access to all Software Development Golden Rules available.

Object-Relational Mapping (ORM) - Overview

Today's talk is about object-relational mapping, what it is, why it is an essential part of software applications. I will then specifically talk (in a later post) about the ORM framework/tool I am regularly using on my projects and provide consultancy on to my clients: LlblgenPro

I don't pretend here to be an expert on ORM tools inner details and design complexity, I am posting here as an ORM tool user and express my return on experience on this matter.

     

It's all about data

The vast majority of software applications are dealing with data and data is the core business value of these applications. May you lose or corrupt this data and you are out of business. In some cases, data is an even more critical asset that also needs to be protected against theft and usage by malveillant people.

    

Data is relational

In the vast majority of cases data is stored in relational database systems. Reason for this is first historical: database systems have been developed over years, and evolved to very performing, scalable, reliable, widely used systems. For such a critical asset of any business, this is not something that will change easily, even though object databases have emerged and are used is some cases. Secondly, the relational representation of data along with the commonly used query language (SQL) are well suited to querying and consolidating large amount of data in a concurrent multi-user mode, computing aggregate information, insuring transactional operations and enforcing integrity of data.

     

Code is object oriented

Object oriented development is now widely accepted and used for its well-known benefits that we will not detail here. Through object oriented design and techniques, code is made a close abstraction of real world and business domain concepts. Many design patterns have been identified that help solve common design problems and leverage the power of object oriented design to build robust, flexible solutions.

    

Impedance mismatch and data access layer

Now we can spot the problem/challenge and the mismatch that exists between application code that is object oriented and need to work on data represented and stored in a relational format. And from a separation of concern point of view we want this mismatch to be encapsulated and abstracted from both the database layer and the application code layer. It is indeed a best practice from a software architecture point of view to separate concerns and loose couple the various aspects of a software project (more on this in a future post). In our specific case we want to have an independent relational database layer created, maintained and optimized by a database specialist who does not need to be concerned at all by the way his data will be accessed and used; and at the same time ensure that application developers can use their best creativity and knowledge on how to efficiently build flexible, robust and maintainable application code in an object oriented fashion without having to deal with the technical intricacy of converting back and forth relational data to objects. And this is where we introduce the data access layer, which purpose is to encapsulate all the tricky details and logic needed to perform the bi-directional transformation between relational data and object oriented application data. From now on, we will name object oriented application data after the denomination of business objects or entities.

          

OK, so can't I develop my own data access layer?     

As developers, most of us have one day developed our own data access layer, taking care of communicating with the database, retrieving and exposing data to the business layers and performing the common CRUD (create/update/delete) actions against the database. After all, this at first does not seem like such a big deal does it? But it very quickly appears that writing proper, efficient and robust data access code is really a hell of a work. For instance how about managing primary keys / foreign keys relationship? How about dealing with strongly typed data rather than simple raw data tables? What about server side pagination? What about complex retrieval of data across multiple tables?

Other fact is that the data access code is highly technical plumbing code that is good candidate to be made generic and thus legitimate the use of a common set of tool, framework and runtime libraries to perform the work for us and concentrate on the core business implementation. So here we are: after writing one's own data access layer on a real, reasonably sized project, one will quite fast conclude that leveraging an existing ORM tool is relevant!

     

So tell me about ORM tools!

One important point to note is that a data access layer does not necessarily have to be ORM layer; in other words, a basic data access layer that only provide encapsulation of the database connections, database commands building and requesting data that is then used by the business layer (probably as ADO.NET datasets) is not a proper ORM layer. The ORM layer goes one step further than a basic data access layer by providing (or connecting to, through a mapping configuration) a business entity model layer on top of the actual data access code and most probably advanced functionalities that can include various interesting stuff like object oriented query language (that could now be exposed through the Microsoft Link extension to .NET languages), web service and distributed application support, auditing, database schema change management, multi-databases, support for data-binding etc.

Using an ORM can therefore save an awful lot of work and give you for free many extra functionality that you can potentially use to improve or extend your applications. The only matter then is to select one ORM tool from the many existing.     

You can see from what exists that ORM tools can be of different nature, you will find:

1. Simple entity objects and data access code generator (which I believe are not really fully fledged and powerful ORM tools). Example could be Code Smith templates.

2. Entity object layer code generator + runtime libraries for data access. Example of such a tool is LlblgenPro.

3. Mapping configuration to connect an existing data store to an existing entity object layer + runtime libraries for data access. Example of such a tool is NHibernate

 

Please note that an ORM tool can also be data centric, model centric or both. A data centric ORM tool will need an existing database schema and generate its entity business model from it; a model centric ORM tool will be able to generate a database from an object entity model. And hybrids ORM tool will be able to connect an existing entity object model and existing database through a configuration mapping file. 

I don't personally find the model centric approach and generation of database relevant. The database should IMHO be designed separately. There are techniques to design efficient well performing databases and I don't believe an automatic generation of the schema is appropriate, except maybe for quick proof of concept prototype or very low load applications. Designing an appropriate database schema is too much dependant on the application business domain and the usage that will be done of it, and the load that will be supported by the application.  

I personally find the data centric approach being the best compromise for most applications. The constraint is that your business model should then be quite close to your data model, which I believe in most business application is the case. It's maybe not the case for warehouse databases designed and optimized for reporting purposes, but there are other techniques than business application development to manage their data and more a appropriate scenario would then to use a specialized data reporting server application (like Microsoft SQL Reporting Services). Another case for which the entity data model might not fit the database schema could be very high load databases for which the database schema has been deeply optimized for performance.

I can see too ways to overcome the constraint of having close entity model and database schema and allowing some divergence between the models. One is to use a hybrid ORM tools allowing connection though mapping configuration between an entity object model and a database schema. However what I don't like about this solution is that you have to write your own entity data model where a data centric ORM tool could automatically generate it for you. Other option is to use a data centric ORM tool and add to the database schema database views that could encapsulate and hide for you the differences between your models. Well of course then you have to handle updateable view or use triggers to manage write operations on the view but hey, that would be the subject of another post!

  

So you now know my preferences. Of course every project has its own specificities and constraints and the choice of an ORM strategy must be revised for every new project. But I always try to save myself the most development work I could, and therefore anytime I can I go for a data centric ORM, because of its ability to generate for you both the entity object model and the actual data access layer, saving you a huge development effort! And my favorite ORM tool, of which I will talk about in a future post, is LlblgenPro.

About my Blog

The intent of this post is to describe the main contents and goals of my blog and what I will be posting about.

   

Main Topic and scope

As the title of my Blog states, the main topic covered is "Business Oriented Software Solutions". It's all about delivering fast time to market, good quality software that answers to business needs and result in a return on investment. 

The type of software projects that are in scope of what I call "Business Oriented Software Solutions" are commercial projects, and are not included research & development, educational projects and any other projects for which there is no associated direct business profitable value. However, all posts that are technical and about development methodologies and quality are still applicable to all projects.

Also not included in "Business Oriented Software Solutions" are all RAD projects and disposable software applications. Disposable software applications can be proof of concept prototypes or software application that are intended for a single, on-off purpose, and discarded away after use. "Business Oriented Software Solutions" are software applications that are designed and intended to be used on the long term and will most probably have to evolve and integrate new or changed business needs.   

This Blog being about software development, there will be a great deal of technology talks. Even though part of the posts will be technology agnostic, another part will be specific to Microsoft and Microsoft partners technologies. This is because I made the choice of using Microsoft centric technologies for the implementation of my software projects and it is therefore the technology platform I am expert on and will be posting about.

   

Target audience

This blog will cover all activities of a software development project and therefore is targeted to multiple audiences. Depending on your level of implication in software projects, you might be interested in certain posts only. Click on your profile below to filter posts of most interest to you.

   

Posts for business owners: As a business owner you will be interested in posts that reunite software solutions and business and explain how software solutions can bring your business added value and exactly fit to your business rather than your business be constrained and limited by a software solution. These posts do not require specific technical knowledge and yet give a nice and clear understanding on software and technical matters from a business perspective.

   

Posts for technical project managers: As a technical project manager you will be interested in all technical and process & development practices posts

   

Posts for functional project managers: As a functional project manager you will be interested in process & development methodology posts and business related posts. You will be especially interested to read about how to drive a project in a feature driven way and through highly iterative delivery cycles.

   

Posts for developers: As a developer you will be interested in all technical posts and in the process & development methodology posts that are related to your daily activities. May be of interest for you two to quickly go through all other posts to get an overall view on how you job fit in the total project landscape.

   

Posts for software architects: As a software architect you will be interested in all technical posts and especially these posts related to software architecture, development practices, tools and frameworks and design patterns.

    

Overview  

This blog is about "Business Oriented Software Solutions" or: how to deliver fast time to market, good quality software that answers to business needs and therefore result in a return on investment.  

This could seem quite obvious and not relevant to be the object of a complete blog: after all, who wants to build and late deliver bad quality software that is useless, not driven by any business case and not bringing any added value? Well, yes, one could tell that software development can be an exclusively creative and fulfilling, passionate activity for some individuals, but as stated above, less focus here on software developed as part of a commercial company strategy. And still: as a passionate individual you may don't care of your creation bringing any added business value and keep it useless yet exciting, but you most probably still want to efficiently produce high quality code!

So obvious answer is: NO, of course no-one wants to create these useless, expensive, poor quality software applications, so why this blog?? Thing is that developing and delivering these Business Oriented Solutions can prove to be tricky and the purpose of my Blog is to gather and consolidate information to provide guidance on how to best choose, use, re-use and compose processes, technologies, patterns, frameworks, tools and applications to deliver fast time to market, feature oriented, high quality, robust and performing software solutions.

I believe that the key to efficiently build Business Oriented Software Solution is to concentrate and excel in two complementary directions:

• Define the goals to aim at and set these goals as your priority
• Clearly understand the various areas of expertise you need to cover to achieve your goals and make sure you have skilled individual on board in each of these areas. 

And for our matter, Building Business Oriented Software Solutions is a real big challenge and the difficulty is to succeed in three main goals: create solutions that are business driven, high quality and fast time to market. 

And building Business Oriented Software Solutions involve mastering complementary skills in three areas of expertise: the business domain/functional space, technology & development practices and management & project methodologies.

  

The three goals for success

One can list more goals to aim at to successfully deliver Business Oriented Software Solutions, and this list can depend on the specificity of a project and/or business domain. However I believe than the main three goals to achieve that are essential and drive success in most cases are to build solutions that are:  

• Business driven/feature driven: solutions answering a real business need and seamlessly adapting to the business changes and evolutions.
• High quality: solutions technically properly designed and implemented making the solution robust, performing, maintainable and seamlessly welcoming evolutions and new features.
• Fast time to market: solution that have the ability to be delivered or more be iteratively delivered as fast as possible, in order to compete efficiently on the market place.

     

The difficulty comes from the interdependency between these three targets. It is for instance easy to understand that reaching fast time to market result while keeping a high level of quality is not so easy to achieve. This is part of the reason why it's common place to have software that are early on the market place but of poor quality, or software that are of good quality, delivered on time but not aligned with the business requirements and priorities, or even worth: software that is not answering the business initial needs, of poor quality due to the pressure involved by fast time to market constraint and delivered very late as a consequence of the two first problems.

The posts will be written with this in mind and will be oriented toward solutions and guidance to succeed in meeting the three targets.

     

The three areas of expertise involved

Various disciplines are to be conducted as part of as software project and these disciplines require different set of skills and abilities that we can distribute in three areas of expertise:  

• Business domain & Functional space: Know and understand the functional space and business domain that is yours. Should not be constrained by technology or methodologies, as business need is the driving force.
• Technology & development practices: Excel in efficiently using technology and composing the right frameworks, tools and patterns to answer a business need in a robust and flexible way.
• Management and project methodologies: Master appropriate management and project methodologies to efficiently and iteratively delivery software with accordance to business needs and technology constraints.

   

Please note that in a software project there are more disciplines than areas of expertise. If we take RUP as an example, the disciplines are: business modeling, requirements, analysis & design, implementation, test, deployment, configuration & change management, project management and environment. RUP is the IBM iterative software development process (http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process) .

You need to be aware that no matter how small or big is your team you will have to master skills in all these three areas of expertise. And the challenge in succeeding in all three areas lies in the inherent difficulty of cross-cutting these three distinct aspects of a software development project that require complete different abilities and most usually different persons who need to communicate and understand each-other and each-other concerns.

      

Outcome of the posts  

Each of the posts that are relevant to creating Business Oriented Software Solutions will be started with tables indicating what goals the discussed topic can help achieve and what area of expertise is concerned and the posts will be tagged accordingly. This way the reader will have a mapping between goals and areas of expertise and a set of relevant posts, ideas, and guidance to succeed in efficiently building Business Oriented Software Solutions.

So here we start, I will now start blogging, I hope you will enjoy the ride!

About Me

 I am Walter Almeida and I intent here to drop a brief description of myself, for sole purpose of making my Blog more lively and personalized and for drawing the background of the posts I will be writing.

         

I am the creator and owner of UNIC International, and the co-creator and co-owner of Pulp Informatique, Microsoft Certified Partner companies. This Blog will be an open window on my thoughts, returns on experience on processes and technologies we use daily at UNIC and Pulp, but more on this in a next post where I will explain what I mean by "Business Oriented Software Solutions"!       

Back to the beginning, here is briefly where I started: I have been in the IT business for more than 10 years now, am passionate with technologies, always have been. I have indeed always loved "creating things" in general, and the flow of life and the chain of decisions and events brought me to accomplish my goals and build my career in the software industry. And I am grateful for being in this business that IMHO happens to be a very challenging, exciting creativity sandbox, and this keeps me alert and happy to go working every day. After all we spend the most part of our lives working, so why not making it a great journey and enjoy the ride?       

I started my career as a software consultant for 5 years, in France, Spain and the United Kingdom, working for several clients in the telecommunication, health, space and financial industries. I started as a developer, first in C language and rapidly moving to C++, language for which a dedicated several years of my working time and it was the language through which I was getting confident to modern object oriented programming techniques and patterns. I remember that I especially loved the C++ template aspect that was much more than the generics we find today in .NET and could be used as a powerful mechanism to perform advanced static (at compilation time as opposed to runtime) programming tasks. This is something I discovered through the amazing book of Andrei Alexandrescu: Modern C++ Design: Generic programming and Design Patterns applied.

         

I then moved from the Consultancy business to be a technical team leader in a leading medical imaging software company based in London. I was responsible for the delivery of Windows based rich applications for the company imaging software solutions. And this was a total new and enriching experience for me and I had to manage a team, handle inter-team collaboration by integrating the work done by the research team, and setup a highly iterative software development process to answer the very demanding company targets and fast changing business directions due to the unexpected nature of research results. It was the first full opportunity for me to build a proper, layered software architecture from scratch while making sure we would deliver time to market solutions in a highly dynamic and demanding environment.

               

I have mainly been working on Microsoft technologies until today and I will keep the same direction in the future. And I am not saying here that one technology is better than another and that Microsoft or any other technology is the best. However I believe than one individual/company should always decide on a set of technologies and tools to use and then train on them, use them and become expert and mastering them. The IT industry is a very fast evolving industry and a technical centric team always has to learn new concepts and new tools in order to keep competitive, so crossing this challenge with having to master the same tools but from different vendors is very tedious and inappropriate in a business oriented vision. It is important to remind that the objective is not to learn new technologies for the sake of it, but because new technologies can bring new productivity gains that can make you more efficient in delivering time to market and high quality solutions. To make a long story short, technology is only a mean to deliver solutions but not a goal, so make your final choice and then go for it! For what I am concerned I made my choice on Microsoft technologies and a set of third party and open source tools and frameworks on which I will discuss in a later post.   

So having worked for years in C++ on Microsoft centric technologies, it was then clear to me that the logical next move would be towards the emerging Microsoft .NET technologies. I always felt in the past that Microsoft was being behind in terms of proper support in their technologies for clean modern object oriented developments. I must say I was quite into their component oriented COM technology but for the rest they lacked of all what for instance Java was providing to the developer community. This was about to change with Microsoft.NET and I therefore left my London based company, came back to Paris for a full year of intensive training on Microsoft.NET technologies, C#, Windows, Web and distributed solution development. It took me a year to get my MCSD.NET certification. I based my training on the development of a concrete multi-tiered application which was an online web application for collaboration and picture Sharing along with a rich client for the administration of communities. I utterly enjoyed developing this solution and learning .NET.

I then decided upon leading my own business and created UNIC International in 2003, followed by Pulp Informatique in 2006.   I keep getting more and more expertise, knowledge and experience using Microsoft Technologies and I am investing now on the SharePoint 2007 collaboration platform, business intelligence, workflows, SOA and am actually developing a large solution following the Software As a Service strategy, but will not reveal more on this at this stage!                

In order to not give of myself a complete geek vision, let's talk quickly about what I do when I am not

thinking or writing or working on technology and business matters! Everyone has its philosophy of life and his own path to happiness, some people place work fulfillment at the top of their life, others make their private and family life the top priority and their job is only a mean to pay for the bills. And each philosophy is equally respectable when happiness is the sole consequence of a deliberate choice, there is no judgment to be made. I am part of those who need both professional and personal realization and give them an equal importance, I would be very sad and frustrated if I would lack one or the other. So I have a great girlfriend, wonderful family and friends and exciting hobbies which provide me with a very good and enjoyable balance in my life. I love to travel and especially when I am able to communicate in the welcoming country language, it indeed makes the whole travelling experience even more interesting and deep! I can speak French (natively), English, Spanish and am currently learning Portuguese, so it makes the choice of travelling destinations very interesting! I love practicing sports which I believe is part of a healthy and balanced life: I run, ride my bike, do fun stuff like body boarding, windsurfing and plan on trying kite surfing. I dive and underwater world is the most amazing thing I have seen so far in my life. And recently starting powered paragliding which is an amazing toy for flying and enjoying nature from the skies! Give you some pictures through this post  And as a bottom line, I am interested in all practices that can lead to better knowledge of oneself and search for inner peace and joy in life, part of this is Yoga, relaxation and meditation, and deep thinking phases. I indeed think that it is essential to try to reunite body and spirit and especially in our modern, fast pace and consumption/material driven European life.

          

What's next?

I will next write about this blog and what I intent to share through these writings.

 

    

Hello World! Proudly writing my first Post!

Hello World! This is my first post!

Here I am at home, after a long day of work, drinking a glass of wine for celebrating my new decision to create my own Blog. It is quite an exciting time I must say, after years of reading very compelling and interesting posts on internet, to decide on becoming an active contributor and start throwing to the world my own views and thoughts!  

I have named my first post "Hello World", after the classical application sample you would write when first trying or demonstrating a programming language, as I actually am writing my first post and shouting "hello" to the connected world, ready to start an interactive sharing of knowledge and return of experience on matters around business oriented software solutions (more on this a bit later!).

     

I want to start my Blog, humm what Blog platform will I use?   

First step was to select a blog platform, there are plenty of them, so comparing them and choosing one appears to be a difficult and time-consuming task. However I had already strong constraints that dramatically reduced the choice: I already discarded hosted Blog platforms and wanted a Blog platform that integrates with WSS 3.0, SharePoint 2007. I indeed have a SharePoint 2007 server and want to integrate my Blog and Blog contents on my SharePoint server for easy integration of my Blog contents with my internet site, leverage the use of the SharePoint search engine etc. Well, first obvious choice is… the new WSS 3.0 Blog site template.

      

First look at the SharePoint 2007 Blog site template: not convincing!

I therefore started by  looking at the Blog site template that ships with WSS 3.0 but my first impression was that the WSS 3.0 Blog template is very limited with regards to many aspects and only offered basic functionality: no anonymous comments, no multiple categories for a single post… and more important: little support for look and feel customization, the Blog theme is still customizable but only through creation of a SharePoint 2007 master page which is all but an easy and straightforward task. And when you start a Blog, the concern is to have an easy setup procedure to start blogging asap and not go through a painful customization and probably coding phase first! I therefore was disappointed and decided on having a look at other available solutions …

 

Community Server: an attractive good looking solution, but…   

After my first disappointment with the SharePoint 2007 Blog, I digged into the internet, remember several nice looking and fully featured Blog, and got though the "Powered by Community Server" link to the Community Server web site and was quite amazed. Hey here we are! Looks like a great Blog platform, which you can host on your server and integrate with SharePoint! Plus you have plenty of extra collaboration functionalities including forums, documents sharing an more.   

However, after a time of high excitement, I came to realise that the little problem was the cost of the solution. Even though you indeed have an Express edition that comes for free, integration with SharePoint requires the purchase of a highly expensive Enterprise Edition… Bummer! back to the beginning, and no still no target Blog platform…   

And after some thinking, it seems not the best to go for Community Server as a full collaboration platform when you already have a SharePoint 2007 that is itself a collaboration platform! So let's try to have a deeper look on the SharePoint Blog site template and see if we can make it a real compelling solution for internet Blogging.  

     

Second look at SharePoint 2007 Blog template: Community Kit for SharePoint  

So let's try to leverage WSS 3.0 and its Blog template. After searching on internet, I found interesting links to solutions for customizing the default Blog template to make it a more relevant, fully feature Blog platform, but no fully ready to use solution… Until I finally found the open source CKS project (Community Kit for SharePoint) and its Enhanced Blog Edition!

From the CKS CodePlex source:  

"The Community Kit for SharePoint is a set of best practices, templates, Web Parts, tools, and source code that enables practically anyone to create a community website based on SharePoint technology for practically any group of people with a common interest."  

And more about the Enhanced Blog Edition:   

"The Community Kit for SharePoint: Enhanced Blog Edition is designed to enhance and extend the functionality of the built-in blog feature in Windows SharePoint Services 3.0"  

And this day, I finally found the solution I would use for my Blog, fully featured Blog platform, fully integrated with SharePoint, free and easy to install (with little subtleties to properly configure anonymous access). And this solution comes with a powerful modular theme framework that allow easy customization of the Blog look and feels without having to deal with the complexities of creating WSS 3.0 master pages. I especially find elegant and convenient the way you can customize the look and feel of the various CKS controls by just changing the XSL file the controls are mapping to.

Just one word about the subtlety when configuring anonymous access to your Blog: not only will you have to configure anonymous access to the WSS site that will host your Blog, but you will also need to perform an extra step to make sure anonymous users cannot navigate your SharePoint lists using the standard SharePoint pages (example : /_layouts/viewlsts.aspx for the all content of the site). The anonymous user would have only read access to the whole content; however this is still a behaviour you want to disable for internet anonymous users. This can be done by activating the ViewFormPagesLockDown feature on the Web application that is hosting the Blog site. More details on TechNet about this. 

And here we are: I am now proudly publishing my first post! So go and try it for yourself, I am so far very impressed and convinced with the Enhanced Blog edition of the CKS 2.0 project. Another great thing is that the SharePoint Blog also integrates seamlessly with MS Word 2007 as SharePoint is known by MS Word 2007 as a BLOG provider. You can therefore use Word to author posts, open and modify existing posts, manage Blog categories etc.

   Publish

What's next?

I will next present myself and talk About me.

I will then talk about my Blog, to introduce the intent of my Blog, what future content I will be writing.