Interesting short article on how/where “Architecture” fits within the business space.
http://www.architecting-the-enterprise.com/blog/2011/11/using-soft-skills-to-promote-architecture-to-the-business/
Scenario below is so common:
“Many Architects find themselves having little influence at the preliminary or vision phases of projects and are often brought into the development at a later stage; usually by the PMO. Unsurprisingly, the point of influence is weakened by this time as many of the key decisions have already been made and the Architect is left to play catch-up and may sometimes be viewed as a barrier by the Project Manager whose prime concern is timely delivery.”
And the statement:
“Most business leaders are concerned with only a small number of factors; usually: Risk, cost, time and return on investment, not necessarily in that order – are usually at the top concerns.”
Is also very accurate although I wish that return on investment becomes bigger priority then what I have seen in the past. Often business will choose cost, time over return on investment.
Friday, 2 December 2011
Monday, 14 November 2011
WSO2 practical SOA workshop
Attended a WSO2 practical SOA workshop yesterday. It was quite good. Quick summary.
WS02 http://wso2.com is an open source middleware company. One of its main offerings is a product suite called WS02 Carbon which is conceptually similar to something like Oracle Fusion. It consists of number of individual middleware products such as ESB, Services Application Server, Business Process Server, Business Rules Server, Governance Registry etc…
One good thing about WS02 product suite is that is built from ground up, it is componentized and it’s well integrated. That is one of the advantages over other commercial offerings as lots of their individual products have been put together by acquisition and made (or forced) to work together.
I have had a bit of experience with middleware products from different vendors both commercial and open source such as Oracle Fusion suite (BPEL, ESB, Rules Engine, Mediator etc…), IBM (WebSpere ESB, WebSphere Process Server, Message Broker etc…), JBOSS (jBMP, ESB) and can confirm that open source offering such as WS02 are truly lean products compared to their commercial competition. Being open source based they are lean in development, methodology, delivery, governance as well as licensing. From my experience quality of the open source products is also generally higher. Less is more. To be fair commercial offerings often provide better tooling, training, documentation and support.
Number and calibre of WSO2 customers is also impressive. It consist of some globally recognised companies mostly in Europe and US (this seems to be the common trend for open source and WSO2 is currently working on creating a bigger footprint in Australia).
Workshop presenters were very knowledgeable and honest about SOA. They presented some real life industry examples of good and bad SOA implementations. Just because companies use the SOA middleware and know SOA theory does not mean they always know how to apply it correctly. Not entirely their fault as there could be number of constraints on their designs such as legacy, political, financial etc…. It comes down to basic principles of minimizing data dependencies, low coupling and using the right technology (middleware tool) for the given problem. Creating a “sane” granularity of the services, equally well balanced message model and separating the domain model from the message model. More coarse grained service and more abstract message model will produce more robust and stable service.
All in all, with complimentary pen, notebook, poster, lunch and coffee a day well spent!
WS02 http://wso2.com is an open source middleware company. One of its main offerings is a product suite called WS02 Carbon which is conceptually similar to something like Oracle Fusion. It consists of number of individual middleware products such as ESB, Services Application Server, Business Process Server, Business Rules Server, Governance Registry etc…
One good thing about WS02 product suite is that is built from ground up, it is componentized and it’s well integrated. That is one of the advantages over other commercial offerings as lots of their individual products have been put together by acquisition and made (or forced) to work together.
I have had a bit of experience with middleware products from different vendors both commercial and open source such as Oracle Fusion suite (BPEL, ESB, Rules Engine, Mediator etc…), IBM (WebSpere ESB, WebSphere Process Server, Message Broker etc…), JBOSS (jBMP, ESB) and can confirm that open source offering such as WS02 are truly lean products compared to their commercial competition. Being open source based they are lean in development, methodology, delivery, governance as well as licensing. From my experience quality of the open source products is also generally higher. Less is more. To be fair commercial offerings often provide better tooling, training, documentation and support.
Number and calibre of WSO2 customers is also impressive. It consist of some globally recognised companies mostly in Europe and US (this seems to be the common trend for open source and WSO2 is currently working on creating a bigger footprint in Australia).
Workshop presenters were very knowledgeable and honest about SOA. They presented some real life industry examples of good and bad SOA implementations. Just because companies use the SOA middleware and know SOA theory does not mean they always know how to apply it correctly. Not entirely their fault as there could be number of constraints on their designs such as legacy, political, financial etc…. It comes down to basic principles of minimizing data dependencies, low coupling and using the right technology (middleware tool) for the given problem. Creating a “sane” granularity of the services, equally well balanced message model and separating the domain model from the message model. More coarse grained service and more abstract message model will produce more robust and stable service.
All in all, with complimentary pen, notebook, poster, lunch and coffee a day well spent!
Tuesday, 9 August 2011
Web Portal
So what is a Web Portal? Like many terms in Technology world it is highly overloaded. In this blog I will try and give yet another (my view) on the Web Portal from my personal experiences.
When I think of a web portal I think of a framework for creating web applications. Depending on the vendor, this framework comes with number of different capabilities and tools out of the box and varying degrees of constraints to use these tools. For example it can come with web content management, work flow driven content management, dynamic customisation, dynamic personalisation, dynamic security, auditing, analytics, staging, performance monitoring, searching, ability to integrate other web app’s, ability to integrate with other enterprise app's via standard protocols such as JSR170, SOAP/HTTP, WSRP etc…
On top of the above mentioned capabilities portal vendor will also provide integration and or basic out of the box capability for the latest collaboration tools wikis, discussions, announcements, chats etc…
It comes with a lot of “free” stuff. But as we all know there is never a “free lunch”. There is always a trade-off and in this case it will be in the portal learning curve, added overhead (non-required features, memory, administration), some technical constraint (library dependencies, platform etc…) and possibly performance (again depends on the vendor). Every web application is different and each case will require business requirement analysis, technology investigation and justification of the decision to use or not use a portal for a particular web application.
Generally speaking portals will provide most benefits for:
So now you are ready to stand up a portal as pure content site, mash up site a wiki server, blog server, document library, collaboration server etc...
But what if you need custom functionality? Let’s look at some of the technology choices that need to be made.
Technology
Broadly speaking web applications run on a technology stack. Anything non trivial that needs more than a stand-alone web server will require a servlet container or an application server (on Java platform).
Technically, portal is a technology layer that sits in between one or many web apps (portal apps) and the application server. Portlet container sits on top of the servlet container and provides the interface to portlets. Portal administrator/developers can group any number of portlets into communities, spaces, custom app to create portal apps.
When there is a need to create custom functionality in the portals this is done by writing portlets. Portlets can be deployed locally (running in the portal container) or remotely (via WSRP protocol). Remote portlets are deployed on a Portlet producer (Portlet container) and are rendered on a Portlet consumer app.
Again depending on the vendor there are variations to this architecture. For example Oracle WebCenter Portal version 11G does not support local portlets, only remote. However WebCenter allows using ADF task flows in its “portal” web applications. Some more detail on ADF task flows vs portlets in Oracle Web Center can be found here.
Many existing web application development frameworks can be used to write portlets. Some of them work better than others and may or may not require a portlet “bridge”. Some vendors provide IDE wizards to make it easier to create different technology portlets e.g. Plain JSP portlet, Struts portlet, JSF portlet, ADF portlet, Spring portlet etc… When deciding on portlet technology, consult the portal vendor on their recommendation as some of the portlets technology will have some constraints on certain portals e.g. JSF 1.0 portlets on BEA WebLogic Portal or Rich Faces Portlets on earlier versions of Liferay Portal. Alternatively perform some comprehensive POT (proof of technology) spikes to ensure that chosen portal and portlet technology play nice.
So there is a lot to think about and decide, safe option follow vendor recommendation for tried and tested technology combination.
Portals can be powerful tools that can provide high return on investment for many companies but there are few gotchas to look out for. They can also be lots of fun for the techies. So if you decide to implement a portal, enjoy the ride and remember (as Lance Armstrong says) “It’s not about the bike”!
When I think of a web portal I think of a framework for creating web applications. Depending on the vendor, this framework comes with number of different capabilities and tools out of the box and varying degrees of constraints to use these tools. For example it can come with web content management, work flow driven content management, dynamic customisation, dynamic personalisation, dynamic security, auditing, analytics, staging, performance monitoring, searching, ability to integrate other web app’s, ability to integrate with other enterprise app's via standard protocols such as JSR170, SOAP/HTTP, WSRP etc…
On top of the above mentioned capabilities portal vendor will also provide integration and or basic out of the box capability for the latest collaboration tools wikis, discussions, announcements, chats etc…
It comes with a lot of “free” stuff. But as we all know there is never a “free lunch”. There is always a trade-off and in this case it will be in the portal learning curve, added overhead (non-required features, memory, administration), some technical constraint (library dependencies, platform etc…) and possibly performance (again depends on the vendor). Every web application is different and each case will require business requirement analysis, technology investigation and justification of the decision to use or not use a portal for a particular web application.
Generally speaking portals will provide most benefits for:
- Modular application development (using portlets)
- Applications requiring features that are provided out of the box by a portal (cms, templating, role based access, collaboration tools etc…)
- Applications that integrate other web or non-web applications and present common look and feel
So now you are ready to stand up a portal as pure content site, mash up site a wiki server, blog server, document library, collaboration server etc...
But what if you need custom functionality? Let’s look at some of the technology choices that need to be made.
Technology
Broadly speaking web applications run on a technology stack. Anything non trivial that needs more than a stand-alone web server will require a servlet container or an application server (on Java platform).
Technically, portal is a technology layer that sits in between one or many web apps (portal apps) and the application server. Portlet container sits on top of the servlet container and provides the interface to portlets. Portal administrator/developers can group any number of portlets into communities, spaces, custom app to create portal apps.
When there is a need to create custom functionality in the portals this is done by writing portlets. Portlets can be deployed locally (running in the portal container) or remotely (via WSRP protocol). Remote portlets are deployed on a Portlet producer (Portlet container) and are rendered on a Portlet consumer app.
Again depending on the vendor there are variations to this architecture. For example Oracle WebCenter Portal version 11G does not support local portlets, only remote. However WebCenter allows using ADF task flows in its “portal” web applications. Some more detail on ADF task flows vs portlets in Oracle Web Center can be found here.
Many existing web application development frameworks can be used to write portlets. Some of them work better than others and may or may not require a portlet “bridge”. Some vendors provide IDE wizards to make it easier to create different technology portlets e.g. Plain JSP portlet, Struts portlet, JSF portlet, ADF portlet, Spring portlet etc… When deciding on portlet technology, consult the portal vendor on their recommendation as some of the portlets technology will have some constraints on certain portals e.g. JSF 1.0 portlets on BEA WebLogic Portal or Rich Faces Portlets on earlier versions of Liferay Portal. Alternatively perform some comprehensive POT (proof of technology) spikes to ensure that chosen portal and portlet technology play nice.
So there is a lot to think about and decide, safe option follow vendor recommendation for tried and tested technology combination.
Portals can be powerful tools that can provide high return on investment for many companies but there are few gotchas to look out for. They can also be lots of fun for the techies. So if you decide to implement a portal, enjoy the ride and remember (as Lance Armstrong says) “It’s not about the bike”!
Subscribe to:
Posts (Atom)