Tuesday, April 29, 2008
As CIO's starting hearing about these industry trends it creates a dilemma for them. Where should they use which solutions. Following is my take on the topic:
As per my earlier post Is SaaS Ready for Prime time? I would recommend that CIO's adopt SaaS solution for non-critical and/or non-differentiation business solutions such as Sales Force Automation, Financial Applications and HR applications. As all the SaaS platform are proprietary I would customize the business process for these solution and make sure not to move/develop and key customer differentiation solutions to these platforms. Not because of security concerns or any of the 'ities. Primarily to avoid lock-in to a particular vendor.
As for cloud computing - not sure I would adopt this as a large enterprise. As a small business, I would be tempted - but isn't it cheaper to rent entire servers on a month-to-month basis from hosting providers like Yahoo!, Verio or GoDaddy? I understand that some very large companies like Google, Yahoo! and eBay leverage such an architecture. I do not have anything against this approach and would love to leverage such a model. However, I would have to agree with Hasso - this is at least 5 years away. To me cloud computing means - I should be able to model my business solutions based on standards such as MDA, BPMN, UML, BPEL, XPDL and SCA using a single tool (don't care if the tool is proprietary, Eclipse or Netbeans). Once the business solution is modeled, I would like to analyze and deploy the business solution (potentially a composite application) to in-house data center (servers or appliances), SaaS provider and a cloud computing provider. In short - I buy into Hasso's business and technology model for Business by Design and their challenge is whether they would be able to pull it off.
Sounds confusing? Yes! it would be - especially if you assume that all this runs on a middle ware. As the technology and standards mature - I expect most (if not all) of the middle ware capabilities to embedded into the Operating System.
- Yogish Pai
Monday, April 21, 2008
As more and more of middleware functionality is going into a chip and network card - the time has come to converge both the OS and the middleware into one single engine.
Workflow: A basic workflow engine that could be leveraged/expanded to execute business logic, user interaction, etc.
Monitoring: Inbuilt configurable monitoring agent to not just monitor the OS but also act as a sensor on the network.
Service Enables: Inbuilt component that invokes the services both local and remote services.
The SO/SO consists of the three layers and is entirely based on the principles of Model Driven Architecture (MDA).
Business Logic: Consists of three major functionality. The extend the workflow to execute business logic based on standards such as BPEL and XPDL. Business rules would that enables business owners to change rules without having to change code. In addition, this rules engine could be leveraged to apply security and monitoring policies. The third component is the event server that included Complex Event Processing (CEP).
Service Broker/Router: Listens to all events and invokes a local or remote service (leverages Service Enabler Foundation) and if it is not found routes the service (either pass through or redirect) to the appropriate destination (leverage Discovery foundation).
Presentation: Includes multi-channel and branding support and support all major presentation technologies.
Tuesday, April 15, 2008
Following is something that has worked for me in the past. Business would refer to Siebel or PeopleSoft application whenever they meant CRM or Order Management. With the help from the LOB-IT (and the decision makers from Business Operations) we were able to get business to start referring to them as Forecasting Application, Order Management application and Lead Scoring Application. It took over a year to change to get business to refer to the business process as applications - instead of getting rid of the term applications.
As a true EA - in all my presentation, budgeting cycle and various leadership team meeting with business - I referred to them as "Business Solution" with no success. Business still called them "Applications". Finally, it dawned on me - it is equivalent to the common vocabulary such as we drive on a parkway and park on a driveway- we most probably will not be able to change this to "we drive on a driveway and park on a parkway" . Similarly I do not believe we can get rid of the term "Applications" (and believe me I did try my best to get rid of it :) ).
Just my thoughts on this topic.
Friday, April 11, 2008
- Procure all the hardware - install, configure and deploy the solution. A pretty expensive undertaking that requires a lot of $$$ - plus additional $$$ for disaster recovery . One alternative would be to rent servers from providers like Verio, Yahoo and GoDaddy but this still requires substantial investment.
- Leverage SaaS platforms provided by companies such as SalesForce.com or Coghead which are pretty reasonable and they do have decent partner and developer program. However, the drawback to this approach is that the solution would not be portable and you are basically tied to their customer base and pricing bundles.
- Get a web hosting solution from a solution provider like Yahoo! (cost approximately $12/month) which includes mySQL, PHP and Perl. Leverage them to develop the business logic and expose them as services. Leverage the social networks platforms like Facebook to develop the User Interaction and release it with limited free features. A great, cheap way to enter the SaaS market on a shoestring budget and once successful - go ahead with alternative 1.
Wednesday, April 09, 2008
I am in complete agreement with you Todd, about needing a retirement plan for the term "application"!!! I share your sentiment about how this ubiquitous term reflects not only the siloed solution that gets built but also in how this term influences the way in which the business need is translated into requirements. Case in point is the way in which I have heard business analysts phrase their questions to the end-user. For example, "How do you expect to act on the information the application provides?" as opposed to asking "How do you or your user community make decisions based on this information?" OR "What is the business context (business rules, policies,regulations etc.) that influence the information?". The business analysts sould divorce themselves from thinking about the application as the "sole repository" of the information and it's current limitations. Analyzing the business user needs and the decision making process might help them discover that these business rules may have already been implemented elsewhere and that the "application" is but one component needed in delivering the targeted business capability. Sadly,this is not the case.
Part of the reason for gravitating toward point solutions and monolithic deployments is the sense of control the solution owner has on the entire solution stack and the confidence factor of knowing that a customized deployment has a better chance of meeting the response time SLAs. It is my hope that the availability of robust standards based deployment platforms may help resolve some of these latent fears. The key however is to recognize that the usage of the term application does influence the final implementation of the solution. Given this, there is ample justification for doing away with the term "application" as it may be too limiting in the realm of today's highly interconnected enterprise.
Doing this may lead to the required behavior change that is needed to move away from the creation of monolithic applications. As suggested by you Todd we may need to be more conscious of the term we use and this could be a simple matter of using a prefix to the term application or it may be that we have to throw the term away altogether. I propose using a prefix of "composite" to qualify the term application to get this desired change in behavior!!
The term application should be semantically equivalent to "applying" a
unique business context to the usage of a common asset such as a business service, legacy system or a business process. This "application" (note,the verb) of value-added business context is focused on delivering a crucial business behavior that offers competitive advantage to the enterprise. With that definition in mind, the term "application" may get a lease for life when used within the purview of the concept of "composite application" that suggests "distributed solution assembly" instead of "monolithic solution creation". Composite applications are mechanisms that help deliver novel business capabilities that are typically translated to"novel" assembly of reusable business services where by the composite application layer performs business context value-addition.
This assembly of business services within a composite application (as opposed to the creation of a monolithic application) enables the enterprise to realize "speed to market" gains from SOA. It also enables an enterprise to move to a model where the enterprise obtains base business services (off the shelf or SaaS style) and uses the composite application layer to apply the enterprise specific business context with the idea of offering distinct flavors of service offerings; thus moving away from the "creation" of solutions to "provisioning" of solutions. (It is worth noting that composite applications are not just deployed in the business layer but also
in the presentation layer in the form of Web 2.0 style mashups.) Finally, I feel that the only way we can move away from the mode of "monolithic point solutioning" to a mode of "assembling solutions" is by making the move to the concept of "composite application" as it breaks the existings emantics associated with the term "application". Following this mindset switch we may be able to completely replace this term as knowledge workers develop a comfort level in both the efficacy of "assembling solutions" at the same time that the vendors build up deployment platforms to help IT meet the stringent SLA needs that are demanded by the business.
Monday, April 07, 2008
The following are the two key principles that are most striking:
Principle 1: provide a clean interface or an entry point and hide all of the details from the caller
Principle 2: provide a layer of indirection between the interface and that of the implementation
It is interesting to see how these "design level" goals re-appear in the realm of architecture with changes only to the scale of applicability.
Principle 1 is supported by design patterns such as Facade, Abstract Factory, Builder and the Factory. Facade hides the behavioral details of the implementation while the others hide details of the details of the creation of a resource or assembly of a resource as in the case of "Builder".
Priniciple 2 is supported by the Bridge pattern that allows the plugging and replacing of any implementation long as the interface is supported.
The idea is not to arrive at a comprehensive mapping of the principles and design patterns but just to do enough to lend support for the core theme being presented here. This leads to only one conclusion, SOA does not preclude the use of good OOAD techniques. SOA just takes these concepts further into the realm of business architecture and business analysis to insure reusability and enterprise wide applicability of the IT asset, in this case a "service". SOA also has been lent support by the standardization of platform agnostic protocols and message model (such as SOAP/ HTTP) and the use of canonical business models (such as XML Schema backed XML).
Your comments are invaluable.
Tuesday, April 01, 2008
As a small business, one may start with solutions provided by Intuit (either on a desktop or SaaS) and as they grow out of it - NetSuite may be a better choice, especially as they provide and end-to-end-solution.
SalesForce.com's advantage is their primary focus on CRM - critical to small business and their AppExchange platform. Based on my initial assessment - I do like it. The jury is still out on whether 3rd party shall develop applications on this platform. If they are successful in attracting the development community - they should be able to go head-on-head with NetSuite - will be interesting to watch.
As for SAP and Oracle on Demand - have not reviewed their solutions as yet.
A web site is key to small business and I do like the Yahoo! Site Solution - easy for anyone to use and did redeploy SOABlueprint using this solution. It just took me a few hours - which previously had taken be over a week to redesign and deploy new content. The only drawback to this solution is that it restricts me from integrating it with Google Analytics or Google Ads. Hope they open it up soon.
Google Sites also provides an alternative and have used it to create the a Collaborative Wiki for SUIT. Google enables small business not only creating a web site using web pages, it integrates Google Apps and the Wiki (JotSpot Acquisition - discussion forum is not yet available). However, once again like Yahoo! they do not allow Java Scripts to be embedded in their pages - once again I am locked out from integrating Google Analytics, Google Ads. and Grand Central - tools that I would like to leverage on all my sites, not just my blog.
In short - SaaS is ready for prime time, especially for small and medium business. However, these companies still need to put in a lot more effort in getting the word out to the market.
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differen...
One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed a...
In this blog my attempt is to provide some definitions and in turn to get feedback on the differentiation between the parameters traded betw...