Shahid’s Perspectives

My friend Eric Spiegel’s just finished a nice article on working with startups. It’s a great explanation to customers on why they should do it and what some of the challenges are. 

The challenge that early stage firms encounter is that customers don’t usually understand they need to deal differently with a startup than an established technology vendor. Let’s be clear what “early stage” means. A company with 50 employees, a few million in revenue and a version three product is not early stage. A company with a handful of employees and almost no revenue with a version one (or beta) product is most definitely early stage.

…

By working with an early stage vendor, you can gain a competitive advantage on your competitors who aren’t willing to take this risk. You’ll have first access to thought-leaders and an innovative product. This will enable you to build and fine tune processes and best practices to get the most out of the new product. When your competition finally discovers the vendor, you will be light years ahead in getting the most out of this investment.

Read more: The Benefits of Working With Tech Startups

If you’re looking for a good overview of available data modeling tools (includes open source and commercial ones), check out this link: Data Modeling Tools.

NIST Special Publication 800-95 addresses security needs for networks in which automated Web services are being deployed in service-oriented architectures.  It’s only in draft but it covers the basics fairly well. If you’re doing business with the government and you plan to offer consumable services it’s worth making sure you follow the recommendations since the NIST requirements will start showing up in RFPs soon.

 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?

eWeek did a decent review of open source (including Java) versus .NET “stacks” a few weeks ago. While the review wasn’t as thorough as I would have liked, the conclusions will let each side to walk away. And, it demonstrates one of the points I’ve been making for years: that open source stacks on a Windows platform are a winning combination. I’m a huge fan of Linux but we shouldn’t drop Windows everytime we think of open source — there’s just as much use and benefits of an open source stack on WinTel as any other platform.

I’ve noticed that most of my clients have finally been convinced that unit testing and regular automated acceptance testing is a “good thing.” However, I’ve noticed that load/stress testing, while moving up in importance, still has a long way to go. Even those doing load testing, though, forget to do proper network simulation to make sure that their tests will valid with “real world” network traffic.

So, the simple advice is to be sure to use network traffic generators and network load simulators when testing your software. A good option is something like Simena. It’s not expensive and works well.