Armedia Blog

Archive for the ‘Software Development’ Category

Software design is in crisis

July 12th, 2010 by A.J. McClary

In the 90’s, when ECM solutions were rare, we could get away with designing solely toward requirements, but there is too much at stake nowadays. A recent study sampling various IT projects reported that:

  • 62% percent of projects fail to meet their schedules
  • 49% are over budget
  • 47% have higher than expected maintenance costs
  • And get this—25% are canceled before they are ever deployed!

If you’ve been in the software industry long enough, you’ve probably seen all of these things happen. The funny thing is, it doesn’t really come down schedule, cost, or requirements—it comes from bad design. When software companies think design, they’re thinking about contractual obligations and meeting commitments with their stakeholders. Here is a typical scenario:

Company wins contract. Client provides requirements. Company builds a solution, meeting the requirements. Testers validate requirements and application is deployed to a set of users. The users hate it and the client makes new requirements, company builds to those requirements, and the users hate the next iteration…and so on.

This can be resolved by utilizing user-centered design principles in your system development life-cycle. Software is not about code, it’s about people. Instead of our clients telling us what they want, we should be telling them what they need. As engineers, we can do a much better job building solutions then they can—that’s what they hire us for. To be successful, we need to incorporate user research, information architecture, interaction design, and usability testing into our process.

“Iteration 0” – 10 Tasks to Guarantee a Slammin’ User Experience

Let’s start with “Iteration 0”. This sprint is completely devoted to user experience. The point is to get out of habit of thinking of Java Beans and database schemas and start thinking about people. Here are tasks that need to be accomplished:

  1. Gather assumptions and requirements. Take some time to get acquainted with the requirements and begin to make assumptions based on your experience with the technology.
  2. Analyze competition. Familiarize yourself with the way your competition handles things. This is not necessarily the solution you should be striving for, but is excellent to have in your back pocket to show how your solution is better or to compare solutions to initiate change.
  3. Understand goals & tasks. Comprehensive user research, interviews, card sorting exercises, and contextual inquiries help identify user needs
  4. Develop personas and scenarios. Evangelize these with everyone on your team. They can be in the form of user stories, posters, work-flow diagrams, and profiles.
  5. Build a content strategy. Find out what content you have, what needs to be developed, what needs to be expanded, and what can be cut. Also create a schedule for delivering those missing gaps.
  6. Information architecture. It’s more than figuring out what content goes where. It’s also what information is most important to your users. Identify those needs and incorporate them into your design.
  7. Prioritize features. One of the greatest advantages of user centered design is that you often find some requirements barely impact your users. Those requirements can be re-prioritized so you can focus on what’s really important.
  8. Build wireframes and interaction designs. Setting expectations on functionality, how it should look, and how it should behave reduces future UI defects.  
  9. Design a prototype. Build something you can take with you to road shows that incorporates both visual and functional design. Update the prototype during future iterations so you always have an accurate portrayal of what the product will look like at launch.
  10. Validate usability. There are hundreds of techniques, including a usability inspection, paper prototyping, and eye tracking, but put something in front of your users frequently.

Points 8, 9, and 10 should be repeated throughout all future iterations until the project’s completion. When user experience drives design, you build products people love to use.

So long, farewell, auf Wiedersehen, eRoom

June 11th, 2010 by Colin Stephenson

A simple goal – “export, transform, load” – the destination is a matter of choice.

EMC eRoom is going away.  It has been marked as End of Life (EOL) so what next?  EMC Documentum have 2 options: EMC Documentum Collaboration Services; EMC Documentum Centerstage.  Armedia’s immediate goal is to support Collaboration Services, then Centerstage but why stop there?  Why limit a client’s choice.

Armedia’s eRoom migration story is in 3 acts (and yes, I have been listening to some test pieces that I used to play in my brass banding days – check out Year of the Dragon by Philip Sparke).

Act I – The Export

Getting the content out of eRoom into an understandable format.  Of course, its not just the content, there is  a large quantity of metadata in eRoom as well.  Act I – The Export deals solely with interrogating eRoom and generating a document detailing everything about eRoom.  From communities to Files.  From eRoom Setup to databases – we mean everything.  The result: a well-formed XML document

Act II – The Transformation

As with any classic performance, after the captivating opening, Act II deals with getting to know the characters.  In this case, the transformation gets to know the XML document and gains a deep understanding of the objects held within.  The transformation is responsible for also generating a secondary XML document. This is formed to support the ingestion to a new Content Management System (CMS) and / or Collaboration System.  Currently the supported transformation is for EMC Documentum Collaboration Services.  This can easily be extended due to the flexible architecture of this utility and is simply a case of transforming XML.

Act III – The Load

The closing act is the build up to the dramatic climax which leaves the audience going “WOW!”.  eRoom Migration aims to achieve the same “WOW!”.  Now that the XML has been transformed you can sit back and let the load run automatically.  That’s it.  By using the ingestion engine of Caliente! loading all the content and metadata is simple.  Just let eRoom Migration take care of everything for you.  The only thing it does not do is say “WOW!” – we leave that to you.

Over the next few weeks I plan to talk in more detail about the approach taken and dig deeper into the 3 different pieces of the migration effort.  For those eRoom users, what do you see yourselves using in the near future?

Doneness!

February 9th, 2010 by Jim Nasr

‘Tis the season for the big sales kickoffs, goal communication, quota setting and the inevitable fudding and jockeying that goes with that. We at Armedia are, of course, not much different and have been dutifully working our list for a while. All roads therefore lead to “Are we done yet?!” Well, some things may never be completely done. And, sometimes, you just don’t know if you’re done or how done is done. That’s kind of like dreaming about having a dream about having a dream…will it ever end! As intriguing as such enigma could be chances are you don’t want to deal with it when it comes to software development. In fact, unless you plan on becoming further fodder for Dilbert, that’s about the last thing you want to do.

Dilbert_software_development

So, how can you achieve “doneness” in software development? There are, presumably, lots of ways…and likely at least one or two not based on divine intervention! Based on our experience, doneness in development (particularly in large projects) is not as much to do with having a cadre of stud developers but having a thorough, systematic and review-laden process that is consistently adhered to. Who knew?!

Here is the gist of our approach to doneness (formal review steps are highlighted in brackets—cannot proceed to subsequent step unless review passes successfully):

Code Design

  1. Document requirements (or change to requirements) to scope level
  2. Get client signoff (FORMAL REVIEW)
  3. Document code design, changes to object model, peer review
  4. Review design (FORMAL REVIEW)
  5. Update system design document

Implementation

  1. Implement test cases
  2. Implement compiled stubs
  3. Review Stubs (FORMAL REVIEW)
  4. Implement services
  5. Integration code
  6. Code review (FORMAL REVIEW)
  7. Update documentation
  8. Documentation review (FORMAL REVIEW)
  9. Implement review changes
  10. Final commit and addition to main build

Other People of Case Management

February 7th, 2010 by James Bailey

A couple more roles although tangential come to mind – evidence administrator and records administrator.  Again, neither role may be primary to closing the case; however both can be critical in ensuring that the case is compliant. 

The case management system may not and probably should not be the evidence management system; however it should integrate with the evidence management system.  At a minimum, the case agent(s) need to understand the chain of custody of evidence associated with their case.  It would be better if it provided richer features like allowing the case agent to request evidence for charge out, reporting on state of evidence within case, electronic representation of evidence (i.e. picture) or etc.  The evidence administrator ensures that the evidence can be found when it is needed for whatever reason. 

The case management system should provide records management services. If deigned correctly, this will be transparent to the case agent.  As you clearly stated in “The People of Case Management”, the system has to make it easy for officers to document their investigation.  The records management system will ensure that the case adheres to the organization’s retention and disposition policies.  The records administrator maintains the file plan with its associated policies and enforces them during the lifecycle of the case. 

The evidence and records administrator supports the case agent by ensuring that physical and electronic material is tracked and available during the lifecycle of the case.

OSGi for business applications

January 29th, 2010 by David Miller

OSGi is a dynamic module system for Java.  An OSGi system is a network of components that communicate via defined interfaces.  Each component is deployable, manageable, and updatable, with predictable effects on the other deployed components.  Each component can be stopped, started, deployed, and undeployed without having to shut down the component host.  Sound familiar?  This is service-oriented architecture (SOA) in a single JVM… All the goodness of SOA, with none of the badness.

If you are a Java developer, or the administrator for a JEE system, most likely you are using OSGi already.  The Eclipse development environment is OSGi-based: Eclipse modules are OSGI components.  Almost every application server is based on OSGi: JBoss, Weblogic, WebSphere.

Using OSGi for a business application should affect your design.  Most systems allocate technical requirements to components.  For the most part, these components live only in the architecture and design.  In most all the projects I’ve ever worked on, the deliverable Java code lives in big honkin’ jar files with little or no traceability back to the architecture and design.  Inside the jar file, every class has access to every other class, and the internal dependencies end up spreading all over the place.  Reasoning about the code base, or pulling out smaller features for reuse elsewhere, becomes very difficult.

In a well-designed OSGi architecture, each logical component from the architecture and design should become one OSGi bundle (the OSGi jargon for component).  Clients have access only to the public interface of each bundle; the implementation remains inaccessible.  Instead of a handful of big honkin’ monolithic jar files, you end up with many small well-defined bundles.  This direct correspondence of one architecture/design artifact (a component) to one development/runtime artifact (a bundle) is what I like the most about OSGi.

Some benefits of a network of well-defined, small components:

  1. Easy to support different implementations of the same interface.  When development starts, you can quickly release stub bundles of the interfaces your team is responsible for; other teams consume your stub bundle to write their own bundles.  As you complete real implementations of each interface, your clients can replace their stubs with the real thing, without missing a beat.
  2. Clients can upgrade only the bundles they’re interested in.  With one big honkin’ jar file, every client has to upgrade every time you release, even if they don’t need the defect fixes or new features in this release.  With a network of small bundles, each client only gets what they really need.
  3. An end to classpath hell.  The OSGi runtime can host different versions of each bundle.
  4. Supposing you are a software vendor, you can package your applications as a set of bundles.  You can offer a basic cheaper system with a few bundles, and value-added features implemented as extra bundles.  Your clients that don’t want or need a NIEM interface, and your clients that want it very much, are both happy.

There are some drawbacks to OSGi for business applications.

  1. Currently using OSGi with plain ol’ Web applications can take some work.  Products like the SpringSource dm Server aim to make this easier.  Also, the OSGi Alliance is working on Enterprise specifications to define how OSGi can be used with JNDI, data sources, JPA, etc.
  2. Java developers have to become a little more aware of design issues.  Most Java programmers I work with want to get their features implemented and defects resolved with as little time and thought as possible.  This is the very genesis of the big honkin’ jar files I keep mentioning… It takes little time or thought to slam out one more class and add it to the one big honkin’ jar file.  This problem should get easier with better tool support.  For example, the Spring Tool Suite and IntelliJ IDEA have first-class support for OSGi development.

InfoQ has an excellent series of blogs to help you get started with OSGi development: Part 1, Part 2, Part 3, Part 4.  Peter Kriens’ blog is a great way to keep up with OSGi news and events.