SOA : The golden bullet of our time

The hype in todays enterprise development world is SOA (Service Oriented Architecture), as enterprises are becoming conversant with this buzz, so as medium and smaller companies are considering joining the band wagon of this development strategies that is gaining momentum in todays enterprise computing.

SOA as the name suggest is a development strategies that tries to put decoupling in mind from ground up by using the notion of services. Although decoupling is un-avoidable when we engineer software/component but to a degree of efforts, SOA allows you to take advantage of seperation of concerns service orchestration, Service Choreography, REST Architecture and Service reusability. Decoupling is bad to some extent because this business of ours is all about integrating stuffs (coupling), there are types of coupling that make sense and there are coupling that makes no sense at all. The following are sample of types of coupling :

Business Coupling : In the real world where we make money and apply both theorical and practical knowledge to software engineering, we cannot avoid integrating systems with legacies and new applications. Business coupling makes sense because we tend to apply rules of data interchange between disparate systems why we avoid any form of tight coupling to reduce the dependencies amongst participants. This is an exact coupling that SOA would allow, the business logic codes are exposed as a service and there are no dependencies between services and consumers. Although business coupling could lead to plumbing if developers do not take into account the tenets of Service Architecture.

Plumbing Coupling : This type of coupling is what most developers that are just finding their ways into true software engineering processes do. This coupling is bad and does not add any value to your assets and infrastructure. In my years of experience, i have encouraged developers and have educate developers to move away from this development practices because as long as you continue to plumb couple, your system will die naturaly without any cause. Plumbing is a sin that we all must have committed one way or the other and the only ways to cleanse ourselves from this sins is to embrace SOA and try to pay back our technical debt by constanly reviewing and refactoring our code.

Having understood the two most common coupling, we should now know where SOA fits in software engineering. SOA allows us to expose business functionalities without exposing the underlying code by enforcing a data-interchage driven by SOAP (Simple Object Application Protocol) by encouraging metadata interchange. SOA is client/devices/platform independent so far we follow the W3C semantics of SOAP and the WS-* specifications.

The Tenets of SOA

1. Explicit Boundary : Service should communicate with themselves in a true and loose coupled manner using agreed messaging construct (SOA encourages SOAP Envelopes). As long as there is no rigourous dependencies amongs services, services should be able to send and recieve messages between themselves without the knowledge of where they are located. Services are platform angnostic by default and should use this effectively. A service boundary starts from the service contract, all communication agreements should should be based on contract.
2. Services can be autonomous: This encourages us all to build services that are independent of other services, and since we cannot achieve one hundred percent service autonomous, we can still strive to build services that are cleanly seperated from dependants, an example of such service is a service which serves as a router or facade for other services. Services can be autonomous: This encourages us all to build services that are independent of other services, and since we cannot achieve one hundred percent service autonomy, we can still strive to build services that are cleanly seperated from dependants, an example of such service is a service which serves as a router or facade for other services.
3. Shared Contract: Service clients talk to services using a published contract. The contract is an interface where service clients communicate with the service. The service client is not required to know the intricacies of the service because the contract sits between the client and the service. Most dependencies are on the contract and not the actual implementations of the service.

To be continued ...

Hit Your Deadlines and Incur Technical debts

We all owe our developments more time to do it right. Software developers are humans too, we can make mistakes, take short cuts , hack , hack , hack and wala! we think we are done , we think we have produced the most changeable solution, the most elegant code, we think we have added value to the business because it works (Hey it works). Well wait until business changes mind, wait until your company buy in a new solution to enhance its business, this is when it will occur to you that you have produced the most crappy software of the year.

Sorry Guys, do not judge me by my writings. I have been in many situations in the past, instead of learning from it i fall into the same pot hole again and again. All in all, software architecture plays a dominant role when building enterprise applications and since i wasn't the architect, i fell into the same pit again.

What is Technical debts

The metaphor "Technical debts" was developed by Ward Cunningham (The man behind wiki) It means design / code / architectural debts that we owe our developments , since we are humans and we want to meet our targets we can bypass some development strategies to make a shortcut, so that we meet the deadlines. Meeting the deadlines doesn't mean we would not re-pay our technical debts (This is one problem that most people/organisations make). We need to go back to the drawing board and re-sharp , this will enable us to learn more on the product and this will strengthen our knowledge of the entire system.

Knowing when to re-pay your debts

You can choose to continue incurring more debts (This will tie you down to the system), or if you are smart enough or at least someone in your team is an anti-hacking developer (A design pattern loyalist) , then you can choose to refactor mercilessly.

Nobody ever said it was going to be easy, but at least you are making the first move to improve your system. Re-paying technical debts is a culture that all software professionals should imbibe. A development team should aggressively encourage this practice , or else none of the team members would come in terms with their weakness or forgotten errors.

I know its good to go faster to the market, but at-least let us look back and re-pay those debts that might come back to hunt us.

What do you think i am doing right now, of course "I am re-paying my debts"

They are here! April 12 2010

If you read my last post about the long awaited Rosairo , you will understand fully well, the richness of what the future hold in stock for all of us.

Come This April 12, the .NET community will experience a change in software development while leveraging the .NET 4.0 and new enhanced WWF (Windows Workflow Foundation), Advanced and Rapid WCF (Windows Communication Foundation) . This will mark the true begining of us all in the .NET Land.

In my experience with developers, catching up with technologies is very difficult because of the rate at which technologies changes in the .NET front. This might leave some developers obsolette because some have'nt tried their hands on LINQ , Extension method , anonymous type e.t.c This isnt nobodys fault but some justifications while this new futures are there. I recently interviewed a C# developer remotely about his abilities on the .NET framework, he said ! ".NET stopped bieign .NET since 3.0/3.5, he went on saying that .NET 2.0 is the best of all."

Everybody is entitled to his/her own opinion, if a new feature appeals to you, use it, if else then throw it away. Visual studio .NET IDE now allows you to switch frameworks, so you can go back to previous framework version.

Never the less, new changes are driven by Customer requirements , bug fixes , industry defined and endorsed patterns. So not to worry, because They are here already!

I cant wait no more , click here to try it out

Software Development Should evolve and not desolve

I have written several titles , i have made a big leap in software development strategies. I have utilized domain engineering culture towards developing software. I am against reactive software development. I talked about AZURE , about Google ready to GO , I took you down to the Spider Web Land while telling how we can be Green too. These are very good articles that reflects the happenings in todays agility driven software world. For this flow to continue, todays topic is how we grow our development process with emerging technologies.

All problems and solutions in software land revolves around how we allow our software development process to evolve. How do we grow our process of development? what can we do to ensure our processes are check listed.

Why should software development evolve?
Enterprises needs solutions that fits in properly into their businesses. They require an extensible software packages that makes for quicker responsiveness in changes. They want to say hey "Lets GO" and we are all moving. But wait a minute, we are all moving ? should we all be moving? As part of movements, we shouldn't move too fast nor too slow, we should allow development to grow from an infant into a more mature development process. "Lets GO" though sound more like carry along, but in most contexts "Lets Go" is used by people who does not know how the software will be build (Imagine a plumber fixing your telephone), so i take the word "Lets Go" as being too reactive.

Software development should be allowed to evolve because its a culture driven activities that we must all conform to, there is no island of knowledge, developers should share knowledge. Strategies/standards/patterns are not paper works, sweet tongues, and big grammars. They are meant to be observed and not to be written down or praised. They are critical to business success and they should evolve as the software evolves.

To complement and supplement evolution of software development, developers should be allowed to use their creativity, software process should have a process too, that means the development strategies should always have its own parent strategies to checklist.

Can we be smart with SMART ?

The SEI (Software Engineering Institute) , developed a migration technique called SMART (Service Migration and Reuse Technique), this enable teams of professionals to actualize reuse SOA (Service Oriented Architecture) pattern properly and deliver what a client wants rather than polluting the entire solution with noise.

Migrating legacy systems are becoming problematic because, if proper planning is not observed, we might end up migrating problems we are trying to avoid.

The SMART initiative allows professionals to engage with customers/end users and document their needs, according to their needs, SMART can be strength ed to cater for it. It allows organizations to identify problem areas before software is reused. There are now several versions of SMART which addresses different problem areas. The following have been developed after the initial SMART Methodology :

1. SMART-MP (migration pilot)
2. SMART-SMF (service migration feasibility)
3. SMART-ENV (environment),
4. SMART-ESP (enterprise service portfolio)
   
5. SMART-SYS (system)

All of these are designed and tailored to needs of the customers. This is how flexible we should allow development strategies to evolve.

Reactive Software Developement ( A Lazy Man Engineering ).

What is Reactive Engineering?

Reactive engineering is a principle that most software organizations tend to follow when they fix and sell. Reactive is reacting to problems that could have been resolved if a proactive means is followed using the following : development trends, processes improvements (SPI) , common sense and having smart people take the lead. Reactive can make organizations believe they are closer to the deadline dates, while it makes them believe so, it become tragic when such reactively built software fails, and cost your company millions , or that reactive solutions is not precise enough and cost lives.

Reactive is not only a problem of software engineering, but a problem for the world, we are not fully prepared for worst cases. This article will only point at reactiveness towards software engineering.

When ever a problem occurs during the development or testing of a solution, reactive tends to fix the problem alone, this is more error prone, because what you think you just fixed may introduce another bug latter on.

For software developers, Continuous Integration can make your unit testing strategies proactive, when you make a simple changes, you will need to run all unit tests to see what breaks and what does not.

Development front has improved over the years. We have experienced the leap from assembly languages, procedural, object and object oriented languages. In this modern day of software engineering where domain principles are adopted to further solve development strategies pertaining to its domain area, software is adopted as part of a necessity for todays businesses to survive and for tomorrows businesses to emerge. This means, many businesses large and small all relies on software for their businesses to run smoothly. But what are we software developers/engineers/architects doing to ensure softwares are built in a proactive manner using agile domain engineering principles as opposed to reactive software development.

Scenario One

Ping Pong (Canonical Naming) softwares are aeronautical software development agency based in Asia, Ping Pong develops software that enable an aircraft control systems. Ping Pong in the early years does not have a clearly defined engineering principles that guide the production of its software (This is counter dangerous because Ping Pong are releasing softwares that does not follow regulations and principles) . This software company is endangering the lives of its users and passengers. Ping Pong, in the other hand are very reactive to software changes and bug resolution.

Although Ping Pong are very reactive, they have not met the standards of software engineering principles because they have refused to follow the ethics and professional obligations to the general public.

In real life there is no such company as Ping Pong, this is just an illustration and an example to show how we may be risking life, billions of monies because we bought a software that hasn't followed due diligence. We do not want reactive software engineering but domain engineering, which will keep you proactive and will make your software resilient to future changes.

Scenario Two

Know All software systems is based somewhere in Europe, know All softwares cannot see beyond itself, it does not recognize the fact that software development has evolves, and there are patterns that enable developers to do it right as opposed to do it any how.

Since Know All seems to know it all alone, they do not realize that tools have emerged and processes have changed and the world is moving forward and not backwards. This organization is the father of all reactive technologist, because they hire people that are good in fire fighting, and people who will hide most software problems under a simple fix called hacking (Again Hackers brothers i do not intend to cross the line). Software development is not an industry of patching, there should be no heroic patching, all stakeholders should follow the same patterns of domain engineering so that people speak the same domain vocabularies.


I will always follow a proactive development practice, it saves time and money and it help prevents the image of the software organizations.