Post-Update: SOA Workshop, NYC February 2010

I’m on my way home from NYC after the SOA workshop (had on last Thursday at downtown conference center). While in a transit of five hours thought of write a post review about the workshop had. This was the third workshop WSO2 did after having two successful workshops in Colombo and West Coast US.
Even we had good number of pre -registrations we were bit worried because of the weather. NYC weather was good on Sunday and throughout the week it turned to bad, by Wednesday night it got worst by having snow with heavy wind. With these concerns we (Paul, Lavi , Miko and Myself) went to the conference room. Without worrying about the bad weather participants did start entering the room. It didn’t match the full number of registrations but a better number than we thought. People had used alternate ways like taking the subway without driving to come to the workshop (due to bad weather) that did show how eager they are to attend for the workshop.
Event did start by Lavi introducing WSO2 to the audience then we went on round table and got introduce each other.
We did start the session with SOA principles and then move to the SOA solution patterns. After a coffee break we did move to ESB, ESB session did drag till lunch. After the lunch I did a session on BPM and BAM (Business driven SOA). Then interesting session came and it was Miko that was sharing his experience using a whiteboard about the SOA adoption. Miko is a expert on that subject that he has written a book on the same. After that we did move to governance and cloud that Paul did deliver an excellent session by proving cloud is not more an buzz-word.
Miko’s presentation did add a huge value because he did talk without wearing a WSO2 cap (a guest speaker) and it was interesting to see how he did look at the SOA and specially about WSO2 products. It was nice to see that an expert on SOA was very impressed about the WSO2 platform. Miko is one of the best speakers I have ever seen that packed with very pragmatic ideas.
The session was all about generic SOA and SOA related topics but crowed was interested on knowing more about WSO2 product family and some were asking on to show how to implement a simple / hello-world solution using the products. Each and every session did drag due to the questions did throw from the audience, but Lavi did the time managers job and moderate the entire session.
We had to return the room on time so we did close the curtains on time and went for a drink to a bar in downtown William street by giving an open invitation to participants to join with us. It was a great to be in a HOT bar in a cold weather like that. We did end the day by going to Miko’s favorite Indian restaurant in midtown for dinner. Dinner went with lot of interesting technical discussions and we did end a productive day.
Feedback was amazing about the workshop and this did encourage us to continue in different locations.  We will be posting about the future sessions in the WSO2 web site, if you are interested or already working on SOA don’t miss the next session. 

Evolution of the Software Architect Role

Working as a software architect for around seven years I figured that the role of the architect got changed with time, and can clearly divide into different stages with the time line.
Traditional Architect : When the role of architect got introduced to the IT job roles/ huarache people use to treat it with compare to the traditional construction architects. Architects used to draw the base architecture of the application/system at the inception of the project. Like we get the blue paper for a building/house the initial architecture done for a system did not change, so it was up to the developers to develop and implementation engineers to deploy the solution based on the architecture done. The SDM (Software Development Model) used in that era was the traditional water fall method and it did fir with the explained architecture approach. Once the architecture is done the architects wash their hands and move to the next application architecture. One of the reasons for the failure of large projects during that period did link with this, that the architecture did not match with the requirement(a), failed to implement or failed to deploy in the target environment.
Translator : Next generation of architects that I call as translators that they did translate the BA (Business Analyst) requirement specifications into a architecture. Most of the time BAs miss interpret the requirements and architects never interfere with the clients. In this time architects were not responsible for the end result and they did draw the initial blue print. The waterfall method and spiral model used as the SDM did fit into the model the architects did follow.
Power-pointer : In this stage architects role ran through slide decks, they were doing presentations from the morning to afternoon and discussing/sharing/training various technical topics with technical and non technical groups. Even the application designs did ran through powerpoint slides and explained.
Pattern Mapper: With the RUP (Rational Unified Process) model and increase the popularity of the design, architecture and deployment patterns architects used to map the entire business requirements to patterns in that time. BAs use to map the requirement into business patterns and architect did map them to the technical patterns. Patterns were error proof so most of the architectures done using this time did work (even they didn't map the exact business use-case).
Knight (Architect Today) : Current role of the architect is totally different from the earlier stages that I did explain. I call him as a knight because knights were the main driving force for the kingdom to win a war (war is a project and we can map the kingdom as the technical organization). Today's role of the architect is more align with the SDM (Agile process) and the business needs. Architect is the technical owner of the application or the project/system from the beginning to end. Architecture done using a iterative manner with align with the agile SDM, architecture spikes will be creating for a specific iteration and modify enhanced with the next iteration. Architect is the advocate to convince business users to buy the technical solutions. Architects need to think lot about the practical side of the architecture they proposed including development, deployment and upgrades as well as parameters like performance, high-availability and scalability. And the knight do have the behaviors explained in the previous chapters that come out with different needs. Architect's role has been complicated based on the system complexity got increased as well as the relation between business and the technology increased. Same time business did start driving the technology rather than the business got adjusted based on the technology delivered. Previous stages architects didn't involve with much coding but modern architects do get the chance to do coding (that they love to) in many instances including building POC (Proof Of Concept), benchmarking and building solutions. Modern architect do more whiteboard sessions than doing powerpoint presentations due to the Agile approach for architecture.   

I have been gone through all the stages explained above during the role I played as a Architect and related roles, today's architect role is more challenging and interesting than the previous stages and it do deliver more value with pragmatic results.

SOA Workshop, NYC

After having two successful SOA workshops in Sri Lanka and in the west coast of US, WSO2 is going to host the third one in the east coast USA (NYC). 

Topics are align with the core SOA concepts but will be more pragmatic. A full day event targeting the CTOs and Architects who are experts on SOA as well as new to SOA. 
Paul Fremantle(CTO at WSO2) and myself will be presenting in this workshop, that we will be talking seven different but interrelated topics.

You can find detailed information about the event from the events page of WSO2 web site and register using the event's registration page.

WSO2 ESB is Unique

ESBs have a big value proposition among the middleware due to the value it brings to the enterprise SOA. Because of that you can find lots of ESBs in the market, some are proprietary and some are opensource. While working as an architect on building medium to large scale enterprise applications I got the luxury to use different ESBs. Once I joined WSO2 I got the chance of sink into the WSO2 ESB by contributing for the development and as Solutions Architect got the opportunity to implement number of user implementations by matching the business use-cases into technical use-cases. This exercise did prove one thing to me that the WSO2 ESB is unique. You might be thinking because I wear the WSO2 hat I'm bias on this statement so I'm going to describe why I think like that during next chapters.
My first point is WSO2 ESB is lightweight. If you look at the binary distribution of the WSO2 ESB it is around 130MB, even in a network that has limited bandwidth this can be download to your desktop quickly. Most of the ESBs that is functionality rich as WSO2 ESB sizes gigabytes and have dependencies to other applications as well (even to start), that take hours to download, configure and run.
WSO2 ESB has package to run as a self extract binary that does not required any other external application. It required a JRE (1.6 recommended but runs on 1.5) only.
Performance is a key factor of the ESB because ESB ads an additional layer to the communication. We have published the last benchmark test sometime back and we are in the process of publishing the latest performance tests with the latest product releases. But from the figures that we found by running the latest releases on our customer places are tremendous, I'm not going to talk about any figures here that the upcoming white paper on that will talk about it. Fast is one of the points for the uniqueness of WSO2 ESB that inherits from the architecture itself.
Most of the ESBs follow a code driven approach to implement the scenarios but WSO2 ESB have an opposite approach that it is configuration driven. Configuration is very user friendly and on simple XML syntax. Inbuilt editor with wizards to generate configuration or user can use any XML editor for the experts to create/edit configuration. This is a very useful feature for architects to implement mediation logics.
WSO2 ESB is not another JBI (Java Business Integration) implementation as most of the other ESBs do.
WSO2 ESB release with the most business friendly license Apache-2.0. Even there are multiple types of opensource licenses some of them have hidden terms that cannot be used freely with business.
WSO2 ESB does not release as multiple editions (community/enterprise etc..), same free opensource edition available for everyone that contains all the features in the product.   
When it comes to deployment you can pick the deployment suites your infrastructure. It can be a single standalone deployment, distributed one with a cluster or multiple cluster groups. Even you can deploy it in an existing application server that is running on your infrastructure with a Servlet container. It contains the key production features like high-availability and load-balancing inbuilt with the default distribution.  
To make the deployment easy WSO2 ESB provides different type of distribution artifacts, standalone binary distributions, standalone distribution that can convert into a web-app that can deploy in a external container, VM (Virtual Machine) images and cloud images (AMIs for Amazon EC2 instances).
WSO2 ESB is based on WSO2 Carbon (with ESB 2.x family of products). WSO2 Carbon provides the development framework and the runtime environment for the WSO2 products including the ESB. Carbon is based on OSGi (Open Services Gateway initiative) technology for Java. As you know ESB is about mediation, with the usage of Carbon you can enable other functionality like service hosting, business-process execution, governance with the ESB. WSO2 got a complete set of products that service individually to fulfill these type of functionality but allows to install set of features as a feature-pack in a Carbon runtime. 
With Carbon I would like to talk about the Carbon UI framework, that builds the comprehensive management, monitoring and configuration UI for WSO2 ESB. It is not a must to have the UI install together you can do a backend, fronted separation and install the two component separately and one UI can manage multiple backend instances too.

ESBs divided into two main categories API driven and protocol driven, WSO2 ESB supports both by using custom mediators and the transports associates with the ESB (using message builders, formatters, listeners and senders).
WSO2 ESB has inbuilt support for most of the web services specifications (ws-*) including the latest addition of WS-Eventing.
When considering the solution architecture WSO2 ESB can use to build small, medium to large enterprise level integration solution using different type of patterns (including MEPs,EIP). 
WSO2 ESB contains a simple programming model that can follow and do any customization or add enhancements. It do support BSF compatible scripting languages that the non Java developers also can use and do programing in top of it. 
I think I have discussed many reasons for why I think WSO2 ESB is unique, best thing is download and figure it by your self. WSO2 ESB contains 100+ samples and WSO2 OxygenTank contains number of articles/KB items to help you to implement your scenarios. Same time you can use the forum and the mailing lists to discuss any clarifications and simply fill the contact form to talk to the WSO2 BizDev team to obtain any specific requirement.

2010 Q1 WSO2 Technical Update

Check out this SlideShare Presentation: This includes the latest technical updates from the WSO2 SOA Platform.

2010 Q1 WSO2 Technical Update

View more presentations from WSO2.