February 29, 2012 Comments Off on Sybase’s new hybrid-threaded kernel architecture
Sybase continues to enhance the performance capabilities of its flagship Adaptive Server Enterprise (ASE) platform. Here’s an article I wrote for Database Journal that describes the new hybrid-threaded kernel architecture.
February 21, 2012 Comments Off on London soapUI training class and speaking engagement on Big Data, NoSQL, MapReduce, and Hadoop
If you’re a software developer, architect, or QA professional and can be in London on March 19 & 20, please visit Skills Matter for the soapUI training class that I’ll be teaching. This two-day intensive hands-on course shows you how to use soapUI Pro to test SOA, Web, REST, and JMS services for scalability, performance, and reliability.
In addition, I’ll be speaking at a public event on Monday night, March 19 at 6:30 pm. The topic will be “Big Data, NoSQL, MapReduce, and Hadoop: Four Concepts that Every Software Architect and Developer Should Understand”. As part of my talk, I’ll be previewing some of the materials I wrote for the upcoming Hadoop for Dummies book.
February 19, 2012 Comments Off on Contrasting Service Oriented Architecture (SOA) with Object Orientation (OO)
At first glance, SOA appears to simply be OO with the Internet factored in. But this is a serious misconception, one that has caused many projects to go off the rails. Bill Blondeau has written an excellent article that contrasts these two disciplines.
Some of my favorite quotes from the article:
SOA is something new and different, with unprecedented capabilities; but it has its own logic and its own requirements. If you treat SOA as merely a different way to conduct the business of OO, it won’t go well. Unfortunately, aspects of IT culture have discouraged treating SOA as anything else.
It’s very easy to fall into this trap:
The IT industry’s reflex, nowadays, is to try to force-fit an Object Oriented paradigm over anything it can, and that’s not always a good idea. (An awful lot of Hibernate, to take just one example out of many, is not very technically valuable; its benefit is mainly cultural rather than technical: pleasing the sensibilities of the OO heuristic community.)
He provides a very useful, five-step guideline for re-architecting monolithic applications. In summary:
- Conduct a thorough business-oriented analysis.
- Compose the results of this research into effective service contract definitions.
- Implement each service as an independent, standalone project.
- While developing the business services – which the Mainstream SOA Methodology labels Entity services – determine any other necessary supporting services. These are commonly known as Utility services.
- Finally, write the application (typically known as Task or Orchestrated Task services) to use all of these services.
Bill closes the article with a list of really smart points to ponder. Here are just two of these suggestions:
Don’t get sucked into implementation discussions (e.g. “Well, should we use SOAP or REST? What about JSON, can we use JSON?”) prematurely. They can easily obscure the points you need to concentrate on in the early stages of your analysis.
On our SOA design projects, I’m frequently asked how to compute the ideal number of services. In the absence of a hard-and-fast formula, try this out:
Shoot for the smallest number of simple Services you can get away with. Obviously, the simpler the individual Services, the more of them you need for a given set of functionality. Balancing Service simplicity against the Service number is an art not a science; do your best, and pay attention to the clarity and maintainability of the resulting suite.
February 15, 2012 Comments Off on Learn REST: a tutorial
As RESTful APIs continue to gain popularity, you might be wondering what all the fuss is about. Here’s a well-written tutorial by Dr. M. Elkstein that explains what REST is, as well as compares and contrasts it with SOAP-based services.
February 12, 2012 § 4 Comments
In this next segment of the continuing saga of what makes an effective sales engineer (SE), it’s time to talk about technical skills. While it’s hard to make sweeping statements, in general the ideal SE will possess a good measure of technical expertise: after all, ‘engineer’ is part of their title.
But technical talents are just the start of the story: it’s even better if they pair this knowledge with hands-on practical experience. Some SEs will have learned your technology as users or developers in an IT shop. Others will have represented competing products at other vendors. And the most motivated candidates will have invested the time and effort to learn it on their own.
Naturally, the ideal technical background is highly determined by the job’s requirements. For example, selling a consumer-oriented SaaS solution has very different necessities than representing infrastructure aimed at software developers.
When I was hiring SEs, I always kept these factors in mind:
- Does the candidate have a degree or not? It’s certainly helpful, especially when selling highly complex solutions or targeting C-level buyers. However, it’s not necessary to have a computer science degree. In fact, in some cases being overly technical can be a drawback – SEs have ‘sales’ in their titles, after all.
- How deep is the candidate’s technical expertise? By necessity, SEs must be spread a mile wide and an inch deep. This can be very frustrating to someone who is very technically skilled and likes longer-term engagements.
- How much relevant real-world experience does the candidate have? A background in implementation and/or managing ongoing operations was especially appealing.
In my experience, the most important attribute is the SE’s ability to rapidly master a new technology; in fact, the most effective SEs delight in picking up new proficiencies and relish the challenge. Find an SE who has a history of quickly acquiring new skills, and you’ve probably picked a winner. One final thought on expertise: don’t forget to evaluate the candidate’s writing skills. Ask to see samples of reports, RFPs, and so on.
February 2, 2012 § 1 Comment
Building a Web application? Want to make sure it runs properly? Have a look at Selenium. It’s an excellent tool to help you automate testing of these types of solutions.
If you’d like to learn more about how to get started, Frank Cohen at PushToTest has created a superb tutorial that shows how to use Selenium to construct functional, load, and availability tests. You’ll find it here.
February 1, 2012 § 1 Comment
We’ve now come to the last of the five most common technical marketing mistakes that I’ve observed – expecting internal team members to produce all of your marketing collateral on a timely basis. Given that Think88 specializes in technical marketing materials and sales methodologies, it may seem like pointing this out is somewhat self-serving – and it is. But my observation is valid whether you hire us or someone else.
Organizational politics often get in the way of overcoming this fault. After all, creating collateral is a big part of the job description for many people in the marketing department. Yet if you were to ask the average VP of Marketing (not to mention the VP of Sales), they’d likely say that they suffer from a significant marketing content shortfall.
If so many people are charged with building marketing collateral, why is there such a critical shortage of these materials in so many companies? I’ve seen three primary causes:
- Staffing. These days, even the largest technology leaders are trying to run lean-and-mean. Unfortunately, as a cost center marketing is often in the crosshairs, even though it performs vital work to bolster sales.
- Prioritization. Let’s face it: supporting active sales cycles is Job One for nearly everyone in the enterprise. Writing collateral is a second or third- level responsibility – at best.
- Vision. Sometimes, internal staff can’t see the forest for the trees. Getting a fresh viewpoint can serve as a catalyst for the whole team.
If you’re faced with trying to overcome a marketing content shortage, bear these points in mind:
- This deficit isn’t due to the laziness or incompetence of your team. It’s most likely because they just have too much to do, and not enough time to get it done.
- Add two to three outside vendors to the team. Naturally, we’d like to be one of them, but regardless of whom you choose, try to treat them as a trusted, strategic partner. Strive for short projects and long-term relationships.
- Use these vendors to fill in gaps. This lets you get materials to market faster, and permits your scarce internal staff to focus on more pressing needs – like helping to close business.