Shahid’s Perspectives

 I saw an interesting service offering recently. Check Autoriginate: Intelligent testing made convenient. Here’s how they describe themselves:

HostedQA is the industry’s first web-based QA solution. With a focus on making automated testing convenient and ensuring that the resulting test scripts are intelligent, HostedQA is generations ahead of the competition. No longer do you have to settle for automating only the playback of your tests. HostedQA automates the entire automated testing cycle. We’ll guide you through everything from setting up your databases and application servers to taking simple-to-understand visual screenshots of each step in the test.

I haven’t had a chance to play with it yet, but I’m going to check it out further.

As many of you know, last year I co-founded the International Association of Software Architects’ (IASA) Mid-Atlantic Chapter and we’ve had some great events in the DC area. This Thursday we’ve got Jeff Nielsen, Chief Scientist at Digital Focus, talking to us about Agile Architecture. Jeff trains and mentors teams and individuals in the use of agile methodologies and has over 19 years of commercial software development experience; he has architected a number of mission-critical and enterprise-level systems.

Jeff’s talk on Thursday, which is being held in Reston from 6 to 9p, is called “Profiling the Agile Architect.” Based on years of experience leading development in a prominent all-agile company, Jeff describes “the ideal architect on an agile software development team”. According to Jeff, “in my work leading and coaching agile teams, I have observed that having an effective architect on the project is essential to the overall success of the project and of the system being built.”

Check out the announcement.

We’ve all seen it: we spend weeks or months in the “sales and demo cycle” for our applications. If we’re lucky we consider all workflows, if we’re even luckier we test drive the UI and make sure training goes smoothly, if we’re smart we also try to ensure that deployment will be easy. However, what we all seem to forget is to figure out how to get out of an application or system after it’s been installed for a while.

Why is getting out important? Because every application becomes “legacy” sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition (”barrier to entry”) is well understood now as something we need to calculate. How about the barrier to exit or switching cost? Do we calculate that when we decide what systems to purchase? Why not?

If you can’t answer the “how, in 24 months, will I be able to move on to the next-better technology or system?” question then you’ve not completed your due diligence in the sales cycle.

When preparing an RFI or RFP, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases. Here are some specific factors to consider:

• Do you own your data or does the vendor?
• Is the database structure and all data easily accessible to you without involving the vendor? If only your vendor can see the data, you’re locked in so be very wary.
• Are the data formats that the system uses to communicate with other vendors open? If not, you don’t own your data.
• How much of the technology stack is based on industry standards? The more proprietary the tech, the more you’re locked in.
• Are all the programming APIs open, documented, and available without paying royalties or license costs? If not, when you try to get out you’ll pay dearly.

If you have other considerations, share them here.

Microsoft has a couple of good articles on Multi-Tenant data architecture, where software as a service [SaaS] applications can all share a single database for multiple customers (”tenants”). The multi-tenant architecture and design is nothing new but the Microsoft guys have done a good job describing it.

Read the article here.

I read a nice article on QA groups: Can’t We All Get Along?.

— We’ve all had days when QA made things difficult. When we take a closer look at what caused it we usually find that there was some miscommunication between QA and the programmers. And this miscommunication was most likely caused by the business having unrealistic expectations of the development team or the business/programmers not understanding the best way to utilize QA. So where does QA fit?