Just Enough Technology » Business

What is an open web?

Dave Ranck — Sun, 14 Mar 2010 19:46:00 +0000

The following challenge was on my Firefox homepage today:

Creating an open web is at the heart of the Mozilla project. And you’re a part of that. As one of thousands of people in the project, you have worked tirelessly to keep the Internet open, participatory and full of life.

The question is: why? Why do you participate? Why does the open web matter so much to you?

As we work to grow the Mozilla community, we want to explain what you’re feeling to everyone — your neighbours, your co-workers, your grandparents. We want them to understand the open web.

I just shared my definition of what an Open Web means to me. Why don’t you share yours?

http://mozilla.org/open
#mozopen

Click read more to see my response

I’m a software architect, specializing in business web apps. Years ago, when the web was young, I attended a technical seminar at which the speaker spoke excitedly about how the web would change the world through freedom of information. It has. Knowledge is indeed power. Never before in human history has so much knowledge been available to many at so little cost. An open web means freedom from those who would control access to information. An open web can literally change and even save lives.

Technorati Tags: Open Web,Mozilla,Freedom of Information

Good Azure Video from PDC09

Dave Ranck — Sat, 06 Feb 2010 03:04:30 +0000

Here’s a great intro to Azure from PDC 09. If you have not looked at Azure or Cloud computing in general, take a look at this video for an introduction. Cloud Computing is here and in use. It will only grow in the near future.

PDC Video on Cloud Computing with Azure

J9SYRP3G9ZUC

Another Security Breach

Dave Ranck — Tue, 02 Feb 2010 05:54:28 +0000

From InternetNews.com :

Hundreds of thousands of BlueCross customers are in for a scare. This week, the insurance company is sending out notifications to its customers fessing up to a significant data breach that saw a thief make off with 57 hard drives from a call center in Tennessee.

The hard drives contained encoded — but not encrypted – records of phone calls and video files containing sensitive patient information. eSecurity Planet has the details on the breach.

Personally Identifiable Information (PII) – it drives companies crazy. We need to obtain it to provide services, but if we mishandle it, we are in for big trouble. This latest case shows that security is an integrated problem. Often we concentrate on having strong passwords and software controls to limit access and guarantee that data only goes to the users who should have access. Yet we leave the front door open by not protecting physical access to servers and thereby the data that is on them. Think of the laptops that were misplaced a while ago. Had they been encrypted, the exposure would have been under control but the company’s reputation would still have been damaged. People don’t believe encrypted data is safe. If a thief can get the laptops or the drives in this case, the average person fears that the data is compromised.

In software and system design we need to pay attention to every aspect of loss prevention and that includes non-technical preventative security measures. I once had a client who spent a large sum of money on a hand reader for the data center main door, but left their database exposed to direct TCP access with the default system admin user name and password still set. Ouch. It is easy to get caught up finding technical solutions to problems like data security and forget to lock the front door at night. In this latest case encrypted drives would go a long way in preventing actual data loss, but once the data physically leaves the control of the company, the company cannot prove that the data was not compromised.

Lesson to be learned: Do not forget the real issues. Address the whole problem homogenously, taking all aspects into account.

Enable Joins WebSiteSpark

Dave Ranck — Tue, 12 Jan 2010 05:26:56 +0000

1/12/2010 – Today Enable Web Technologies has been selected to join the Microsoft WebSiteSpark program. Enable Web Technologies (www.enablewebtech.com) is the consulting company owned by myself and Victoria, my wife. We recently joined the Microsoft WebSiteSpark program.

From the FAQ on the WebSiteSpark partner site:

The program helps Web Pros drive new business opportunities through increased visibility and connections with partners (including Web Hosters) and customers around the world; WebsiteSpark also provides Web Pros with Microsoft tools and hosting solutions, as well as support and training.

WebSiteSpark gives Enable access to emerging technologies from Microsoft and a network of complementary professional service companies in the web space. This program and our nomination for participation provides a strong foundation on Microsoft technologies for our clients.

Choosing Between Java and .Net

Dave Ranck — Tue, 29 Dec 2009 07:22:25 +0000

Another Blast From The Past Article – Originally Published in Oct. 2004

I’ve been going over some articles I wrote over the years and have resurrected a few for Just Enough Technology. They are interesting in that the ideas are (usually) still valid and relevant in today’s world. This article was the basis of my focus on .Net over the last 7 or 8 years. I’ve created significant applications in both Java and .Net, and I am a great believer in choosing the right technology for the job. That could be Java or .Net or something else. This article contains some tidbits of truth concerning selecting the best technology based on real criteria – that is, criteria that are based on solving a business problem, not an arbitrary preference.

How does one go about comparing the relative strengths of and differences between the Microsoft .Net platform and the J2EE platform?

This question is being asked daily in one form or another in companies across the globe. In today’s Enterprise Application development world, there are 2 main players in the arena: Microsoft’s .Net and Sun’s J2EE. IT directors, CIO’s, software architects and developers are faced with the choice of a platform on which to base not only their next application, but possibly the company’s core applications for years to come. This decision is important to IT’s ability to respond to business needs, now and future and involves not only the evaluation of the technology itself, but of the company or companies behind the technology.

One might conclude that because of the importance of these decisions, that due diligence is routinely applied and objectivity is maintained when making such decisions. In my experience working with Fortune 1000 clients, I have surprisingly observed this not always to be the case. Often, management is influenced by the well-intentioned leading of respected technologists within the organization, who, though they thoroughly understand the technology they recommend, are not necessarily objective in their comparative evaluation of competing technologies. In some cases, I have seen this lead to the adoption of a technology platform which was just wrong for the company and which was ultimately discarded (incurring the cost of reworking the applications in another technology).

Before I continue, let me first say that I have a firm opinion on this subject. It is an opinion that has been reached through much experience, both hands-on as a software architect and from a high level as a business development consultant and architect. My purpose in this brief article is to outline my thinking and criteria for reaching this opinion, more than it is to present my conclusions. Perhaps there will be a follow-on article where I will dissect my reasoning more completely. Let me also state that I have designed and developed successful, even award-winning applications in both platforms. Core to my conclusions is the firm belief (borne from experience) that is equally possible to design performant Enterprise applications in either platform.

There are at least two components that must be considered when comparing these platforms; the technology itself and the company behind the technology that you will be partnering with. Starting from the preconception that either technology enables high-performing, enterprise-level application development, we must seek out the differentiators of each technology and its vendor(s). If both technologies support true enterprise application development, do they handle this task in the same manner or with the same degree of ease? Of course not, so lets list a few of these differences. For now I’ll simply list the individual points and we will cover them in more depth in a later article.

.Net

A single vendor solution
Designed to specifically integrate with many other supporting applications from the OS, to the database, to satellite applications such as BizTalk and CMS.
Includes the best, most efficient development environment (IDE) available today (in my opinion).
Greatly facilitates UI development, particularly web UI development (this will be enhanced even further with the upcoming release of ASP.Net 2.0),
Allows multiple language use
Limited to the Windows family of server OSs.
Very good direct vendor support with add-ons and architecture guidance from the vendor.
Lends itself to faster time to market development timeframes.
Tends toward a horizontal scaling architecture

J2EE

A multiple vendor solution
Each vendor supplies differing supporting applications such as a CMS or workflow management system.
Each vendor supplies a differing application server such as WebLogic or WebSphere.
Core code is based on the same JDK.
Multiple vendors provide IDEs with different capabilities.
Provides Open Source implementations of functional packages that may or may not find their way into the core (Struts for example).
A single language solution (theoretically it is possible to create compilers and runtimes for other languages, but it is not done in practice)
Runs on multiple OSs.
Support is dependent on the vendor and may involve multiple vendors if a number of vendors are chosen for various facets of the architecture.
Tends toward a vertical scaling architecture

Reaching a conclusion

The process for reaching a conclusion on an architectural platform must as we mentioned take into account the company(ies) behind each platform as well as the relative merits of each platform. If you know me or have been following my .Net site, you have divined that my decision has been for .Net. Part of my reasoning is that .Net is, for the most part, a single vendor solution. That is certainly not to say that .Net is not supported by a multitude of third party vendors, but the core framework is managed and developed by Microsoft. I believe this brings a decided edge to .Net in that Microsoft can coordinate efforts (as they are doing with .Net and Yukon) to strengthen .Net through supporting technologies. IBM can do this to some degree with the WebSphere family, but in practice it is more difficult for Java provider. If IBM is chosen as a vendor and the intention is to utilize many of the other WebSphere family of products, in essence, a decision has been made to go with a single vendor. It may be a good decision at that. What can be lost is the ease of porting applications or code to other vendors products or the ease of integrating other vendors products. This is one reason why I believe interoperability is of greater relevance than portability.

Another factor in reaching a decision must be the corporate culture of your organization and its openness to new ideas and new ways of thinking. Current skillsets must also be considered, but must not become the sole or even the major criterion. Skills can be taught or acquired through hiring. An objective evaluation of these factors must be made. If the IT group just does not like the technology chosen, successful implementation is almost impossible. In addition, the cost to retrain developers in a different technology must be appreciated.

When all is said and done, the criterion that should be foremost is the bottom line: Which platform will enable the highest positive business benefit? This is not always measured in terms of hard dollars (though it certainly often is), but in terms of “soft” dollars – productivity gains, client satisfaction level gains, employee satisfaction level gains, etc. It seems foundational – but also seems to be often forgotten – that software has no meaning unless it provides some business benefit. The greater the benefit, the “better” the software is. Technologists often concentrate on the internal benefits of software – it runs faster, it handles more transactions, etc. While these considerations are part of the equation, the bottom line is the relative business benefit. For an extreme example, an application built to handle hundreds of thousands of transactions but that takes thousands of developer hours to construct, test and maintain, may not have great relative business benefit for a departmental intranet application.

One more thought on this idea of business benefit. When evaluating software or platforms, it is important to correctly separate the benefits from the features. OK, it’s time for a pop-up quiz!

Which of the following is a benefit and which is a feature?
a. The architecture is scalable
b. The architecture can handle 500,000 tpmC

OK, this was a trick question, sorry! Actually, both answers are features. The benefits of these features might include things like: “Users will not experience application slow-downs even at peak usage times” or “We will not incur extra costs for rearchitecting the solution even if our user base quadruples”. You get the idea.

So what does all this have to do with choosing between J2EE and .Net? These ideas are basis of my thought process in making my evaluation. They are certainly not the only criteria, but I believe they describe how I think about technology in general. It is because of how I view technology as a part of the greater scheme of business in general that I am drawn to .Net and other Microsoft technologies. I always have the end in mind. The software is the means and not the end. The overall benefits of .Net in terms of development efficiency, ease of development, tool support, forward thinking by the vendor, and timely innovation lead to applications that can be developed faster, at less cost and with more features in my experience (providing greater business benefits).

One last illustration. We are all familiar with the resource triangle. There are three components to any development effort: Resources (people and dollars), Time and Features. They are all inter-related. By basing an architecture on a platform that can cut development time, add features and in some cases, cut resource costs, we have a winning solution. For me, that winning solution is .Net.

Addendum: Perceptions

The following are a few perceptions that are not based in hard truth, but are what I call “perceived truth” – preconceptions based on the perceiver’s viewpoint or other unrelated factors:

J2EE is more “industrial strength” -
this is simply untrue, though it can be said that some J2EE applications are more industrial strength than some COM or .Net applications. In a later article, we’ll explore this preconception more thoroughly. One reason for this perception, in my opinion, is the accessibility of Microsoft development tools. Microsoft has done an excellent job providing great tools that enable users who are not expert-level developers to create usable applications. One side affect of this is that some of these users attempt to build enterprise applications without the base understanding of the requisite architecture, design and best practices. There are no practical limits to the strength of .Net applications but best practices for architecture and design must be followed, both in .Net and in J2EE.

.Net is good for Rapid Prototyping or departmental applications, but the core architecture should be J2EE based -
It is true that .Net lends itself better to Rapid Prototyping and smaller, departmental applications, but this does not obviate its ability to be used to create true Enterprise applications. What is true, is that it is much more difficult to create departmental projects with J2EE. This has do in part with the innate complexities of OOP that are usually not compensated for by the J2EE IDEs. J2EE in general does not easily lend itself to adoption by mere mortals, so to speak.

All of a company’s applications must be built using the same platform. We need to rewrite all of the legacy applications now -
The truth is that legacy applications have had a lot of investment poured into them over the years, both in terms of dollars and in terms of knowledge. In the real world we live in today, it is important for applications to interoperate, both to support legacy applications and to support the common reality that, especially in larger companies, more than one modern development platform may be present. Both J2EE and .Net provide the foundations for this kind of integration, though there are (of course) implementation differences.