From the first day that a non-technical end user started using a custom web application developers and users alike have been pining for web applications that behave like traditional client side desktop applications. The high volume sites out there like Dell.com, Amazon.com, Google, etc all stick to basic standard web application navigation and behaviors. They use links for navigation and simple lists for order items on a screen. Most of the sizzle is just animation or video displayed within the Adobe flash player. There is a reason for this… these techniques work and work well for what the web provides.
Still, users and developers are constantly trying to bring more desktop application style behavior to the web. This effort has resulted in a class of web applications known has Rich Internet Applications (RIA). Google made this popular by using existing technologies that have been available in the major internet browsers for a long time but just hadn't been utilized. Web developers shied away from these because they had been bit by browser rendering inconsistencies for so long that they avoided it to make their life simpler. Over time the common browsers got more mature and this functionality became more consistent and sites like Google started taking advantage of it.
The technique Google and others began using was given the name AJAX. It is a combination of Javascript , XML, and Asynchronous calls from the browser back to a url or service on a server to update and get new data. Multiple Javascript libraries ( such as Dojo and Prototype ) became popular because they provided a common framework for presenting desktop like behavior such as drag and drop and other visual effects in a web page.
Another technique for providing RIA's is found in the Google Web Toolkit (GWT) and OpenLazlo. These two tools follow the same basic architecture. They created a Java framework that contains User Interface Components with behaviors that mimic the behavior of their Javascript based framework that gets deployed in a web application. To develop in these environments all the user interface functionality is coded and tested using namespaces and components in the Java framework in a Java IDE like Eclipse. Then when the application is ready to deploy a utility supplied in the toolkit converts the source to Javascript that utilizes the Javascript version of the same user interface components. The Javascript is what gets deployed to the web server.
The third technique for providing RIA's consists of having a runtime component that runs as a plug in to the browser on the client. The three more popular tools for doing this are Adobe Flex which utilizes the Adobe Flash player, Microsoft's Silverlight which uses the Silverlight plug in, and Curl which utilizes the Curl RTE. Also a fourth option is the new JavaFX which utilizes the java runtime plugin for the browser in the same fashion that Java Applets would execute in a web page.
All four of these solutions have the advantage that development can occur in an IDE much in the same fashion as a desktop application would be developed. They all provide support for multimedia as well as straight UI and forms development. Some of these solutions (Adobe Flex, Curl, JavaFX) provide the capability of running the applications from a server or they can also run from the desktop. All of these solutions provide the capability to interact via Javascript with other elements on a web page.
Deciding which one of these is right for your RIA can depend on multiple elements. If you are a Microsoft shop then Silverlight is going to be the way to go because if you have Visual Studio 2008 or plan to upgrade soon you have all the tools you need. If you already work artists and web designers that use Adobe products you may want to lean towards Adobe Flex because the interchange of graphics between the designers and developers will be easier. If you are a Java shop you have multiple options. GWT, OpenLazlo, and JavaFX are all Java centric and may be an easier transition.
If you want your web application to stand on its own and not require any kind of a runtime then GWT, OpenLazlo, or straight Ajax using a framework like Dojo or Prototype may be the way to go. Before you get too hung up on requiring a runtime though consider that most people have already accepted the Adobe Flash player plug in their browser because so many sites use it for multimedia functionality. Microsoft through their automatic updates are going to make sure that Silverlight is on everyone's Windows machine so chances are they won't have to install it to view your web site. Also these concerns are only if you have an Internet facing site, if you are considering these for an Intranet site where the desktop environments are controlled then requiring a run time plug in shouldn't be an issue.
There are a couple of software development guidelines that should be followed when using RIA's regardless of which one is chosen. The first key thing is that only use the tool (Ajax, GWT, Adobe Flex, Silverlight, etc) for User Interface. I can't emphasize this enough. ALL business logic should reside back on the server and be accessed via services calls. Do not try and put all your application code in Javascript, ActionScript(Adobe), Silverlight (C# or VB.Net). I have seen many RIA projects fail because they try and put the whole application in the RIA environment and just make data CRUD style calls back to the server. The RIA solution should be used for seamless, flashy, or sizzle type user interface effects or functionality and not for handling invoice transaction logic.
Another key factor is to keep the User Interface side of the code separated by visual components and artifacts and coding logic. Adobe Flex and Silverlight do a nice job of this just based on how these tools are architected. If you are using an AJAX type solution then that separation is done totally through development project management and not necessarily inherent in the tool.
So what are you waiting for try one of the technologies mentioned above and code away.
Monday, September 1, 2008
Sunday, January 6, 2008
Who is this Architect person and why do I need them?
The term Architect within the scope of IT has many definitions:
Data Architect - Responsible for design and management of the data that supports the organizations applications including database technologies, storage technologies, and Business Intelligence tools.
Software Architect - Responsible for the design and management of the software applications that support the organizations business processes.
Infrastructure Architect - Responsible for the infrastructure ( network, equipment, desktop applications, etc) that supports the organization.
Security Specialist - Responsible for security of systems with in an IT ecosystem. I have not yet heard them referred to as Security Architects but they are filling that role.
Solutions Architect - Responsible for the technology and implementation of a solution. This role requires the most experience and breadth of knowledge. This person must assimilate the information from all four disciplines (applications, data, security and infrastructure) and ensure that the best combination is being used for a complete solution.
In addition to Architect roles in these disciplines there are also people referred to as Cisco Architects, Oracle Architects, Microsoft Architects, etc. I don't want to downplay the knowledge these individuals have but I don't feel you are an Architect if you only know or work with one vendor or product. We'll get to that a little bit more later.
The responsibility of the Architect role is to utilize technological solutions to fulfill business functionality needs. The Architect needs to have both the high level vision of the solution and at the same time be involved with smallest technical detail.
This individual interacts with the end users and stake holders to understand the business processes that are being implemented. They assist the business in making solution decisions utilizing their knowledge of existing technology and also new or related technologies that are available. An architecture role is one of constant learning. In order to provide value in making short and long term technology decisions they need to be current on what is available in the marketplace in addition to what is already implemented within the current environment.
An Architectural role is not a managerial role and does not have direct reports unless your organization is large enough that you have multiple architects. (Generally organizations are lucky if they have one let alone multiple). One of the key skills of an Architect is that they are a facilitator and not a dictator. They must have the people skills that allow them to design and implement the architecture based on a collaborative effort with other implementers on a team and in the organization.
The "Ivory Tower" syndrome is something that will make the Architect role totally ineffective. They cannot just go into their tower and draw up a design on stone tablets and present them to the implementation team as the ONLY solution. There are always multiple ways to design an implementation that are all technologically sound, an architect must be willing to for go his personal preferences if the design recommended by the team doesn't have any technological issues. Conversely he must stand his ground if the development team wants to do it a certain way out of convenience but in a way that has technological short comings. Sometimes it takes some coaxing to get people to try something different but if it is a sound design a good technology person will at some point during the implementation will see the value in doing it one way over another and they will buy in.
Also an Architect should take on part of the implementation duties. They should write code, configure environments, work on deployment scripts on different projects at different times. Be wary of the architect that doesn't actually do the work on occasion. There are many "academic" architects out there that I feel are not as effective because they have not used the tools and debugged an issue or worked through a technology problem. When there is problem that is when you learn and improve your skills. If you are doing everything in a document there aren't ever any problems with that.
Effective Architects come from a background of broad experience. As I referred to earlier, I don't feel that someone that is specialist in one particular product is a good general architect. An Oracle Architect would not make a good Data Architect because their solution would always be something Oracle which may work but may not be the best fit. (Its the old adage "if your only tool is a hammer everything looks like a nail") The vendors love the Oracle Architect but the best overall solution for the organization may not be implemented.
Vendor marketing material and sales folks can always make their products sound like they can solve your organizations implementation issues, that's their job and most do it well. It's an architects role to sift through that and find what's real and determine if its the right fit for the organizations solution.
The key aspects that an architect brings to your project or organization is that end to end vision from a technology perspective, facilitating collaboration between the different IT disciplines (data, infrastructure, security, development), and facilitating implementation processes.
Data Architect - Responsible for design and management of the data that supports the organizations applications including database technologies, storage technologies, and Business Intelligence tools.
Software Architect - Responsible for the design and management of the software applications that support the organizations business processes.
Infrastructure Architect - Responsible for the infrastructure ( network, equipment, desktop applications, etc) that supports the organization.
Security Specialist - Responsible for security of systems with in an IT ecosystem. I have not yet heard them referred to as Security Architects but they are filling that role.
Solutions Architect - Responsible for the technology and implementation of a solution. This role requires the most experience and breadth of knowledge. This person must assimilate the information from all four disciplines (applications, data, security and infrastructure) and ensure that the best combination is being used for a complete solution.
In addition to Architect roles in these disciplines there are also people referred to as Cisco Architects, Oracle Architects, Microsoft Architects, etc. I don't want to downplay the knowledge these individuals have but I don't feel you are an Architect if you only know or work with one vendor or product. We'll get to that a little bit more later.
The responsibility of the Architect role is to utilize technological solutions to fulfill business functionality needs. The Architect needs to have both the high level vision of the solution and at the same time be involved with smallest technical detail.
This individual interacts with the end users and stake holders to understand the business processes that are being implemented. They assist the business in making solution decisions utilizing their knowledge of existing technology and also new or related technologies that are available. An architecture role is one of constant learning. In order to provide value in making short and long term technology decisions they need to be current on what is available in the marketplace in addition to what is already implemented within the current environment.
An Architectural role is not a managerial role and does not have direct reports unless your organization is large enough that you have multiple architects. (Generally organizations are lucky if they have one let alone multiple). One of the key skills of an Architect is that they are a facilitator and not a dictator. They must have the people skills that allow them to design and implement the architecture based on a collaborative effort with other implementers on a team and in the organization.
The "Ivory Tower" syndrome is something that will make the Architect role totally ineffective. They cannot just go into their tower and draw up a design on stone tablets and present them to the implementation team as the ONLY solution. There are always multiple ways to design an implementation that are all technologically sound, an architect must be willing to for go his personal preferences if the design recommended by the team doesn't have any technological issues. Conversely he must stand his ground if the development team wants to do it a certain way out of convenience but in a way that has technological short comings. Sometimes it takes some coaxing to get people to try something different but if it is a sound design a good technology person will at some point during the implementation will see the value in doing it one way over another and they will buy in.
Also an Architect should take on part of the implementation duties. They should write code, configure environments, work on deployment scripts on different projects at different times. Be wary of the architect that doesn't actually do the work on occasion. There are many "academic" architects out there that I feel are not as effective because they have not used the tools and debugged an issue or worked through a technology problem. When there is problem that is when you learn and improve your skills. If you are doing everything in a document there aren't ever any problems with that.
Effective Architects come from a background of broad experience. As I referred to earlier, I don't feel that someone that is specialist in one particular product is a good general architect. An Oracle Architect would not make a good Data Architect because their solution would always be something Oracle which may work but may not be the best fit. (Its the old adage "if your only tool is a hammer everything looks like a nail") The vendors love the Oracle Architect but the best overall solution for the organization may not be implemented.
Vendor marketing material and sales folks can always make their products sound like they can solve your organizations implementation issues, that's their job and most do it well. It's an architects role to sift through that and find what's real and determine if its the right fit for the organizations solution.
The key aspects that an architect brings to your project or organization is that end to end vision from a technology perspective, facilitating collaboration between the different IT disciplines (data, infrastructure, security, development), and facilitating implementation processes.
Subscribe to:
Posts (Atom)
