For a long time I have resisted the urge to convert to keeping my log on the computer in electronic form. First of all, I’m not that good of a typist so I often get distracted correcting spelling when I should be letting notes, conversations, and ideas flow through my hands to the page; I can write much quicker than I can type. Secondly, I like to draw simple pictures, arrows, boxes, etc. in-line with my notes to better express ideas and solutions; that is much more difficult on a computer.

There are certainly disadvantages to taking notes in a notebook with a pencil. I usually have to transcribe the information I collect or invent into reports or technical documents, which makes it seem like twice the work (It isn’t really, it’s reinforcing the information.). I also can’t full-text index a notebook — though I had a colleague who tried — to instantly find the page I am looking for. I have to browse through the pages.

The point is, regardless of the medium, I believe it is essential for all professionals to keep a log of some kind. Beyond the obvious benefits of keeping a record of activities, I believe there is something very therapeutic and cognitively-beneficial about taking the time to summarize your day’s activities, the solution you designed, or the brilliant idea you just had. You often learn something by explaining it to someone, in this case, yourself. Obviously our founding fathers believed that too since we have libraries full of journals from Adams, Jefferson and Washington (to name a few). And if you are a fan of StarTrek (you pick which flavor), you know that “logs” play an invaluable role in understanding other cultures, civilizations, and ourselves.

It is never too late to start. So, pick up a pencil, flip to a clean page, and record your most profound ideas — or just your daily activities. I think you will find it helps you grow as a professional in many ways.

The rule of “Fast/Good/Cheap” states that a customer can choose only two of these attributes to maximize. The third, unchosen attribute, will naturally suffer. This is a physical constraint of a triangle, and a realistic constraint of a project.

If you consider the area of a triangle to be constant and represent the scope, or requirements of your software project, you can create numerous triangles to model the “Fast/Good/Cheap” rule. For example:

Remember, the area of the triangle (scope of the project) must remain constant. Therefore, a change to any one side of the triangle necessarily affects the other two. The implications are these:

• Good & Fast = Expensive. High quality software will be produced very quickly to meet a customer’s time constraint. However, this approach will require additional staff, extended work hours, additional testing, etc. — all things that will drive up the cost of the project.
• Good & Cheap = Slow. High quality software will be produced; however the project tempo will be slow. Other projects will take priority over this project and interrupt its schedule frequently.
• Fast & Cheap = Poor Quality. The project will be done quickly and on a shoe string budget, and you will get what you pay for. Don’t expect all of the requirements to be met and expect some bugs and unpredictable behavior because the development team didn’t have the time or resources to thoroughly design or test the software.

In reality, everyone wants Good & Fast, but can’t afford it so they settle for Fast & Cheap. Then one of two things happen:

1.  Inferior, non-compliant, buggy software is delivered that the customer is unhappy with and your company gets a bad reputation for poor quality.
2. You and your staff absorb all the cost and overtime required to produce quality software on an unrealistic schedule with an insufficient budget (because you are perfectionists). You are lauded as heroes, but the project actually cost you money instead of making you money.

Ideally, you strive to strike a balance among these competing constraints, although some projects will justifiably favor one attribute over another.

All complex systems are difficult to model, and the software development process is no exception. This very simple model can be used to easily and quickly demonstrate to customers how changes to any of a project’s constraints (Fast/Good/Cheap) will effect the other constraints of the project. I have used this model numerous times to demonstrate how these constraints relate and the consequences of changing or over emphasizing one of them. A picture is worth a thousand words and customers usually get the “Fast/Good/Cheap” rule immediately once you draw the triangle. And best of all, beyond its obviousness, there is a lot of solid project management research and data to validate it. I will leave that reading to you.

The CONNtext solution enables real-time bi-directional synchronization between IBM’s Maximo Asset Management suite and IBM ECM suite The solution provides the capability to leverage controlled documents to handle asset configuration management in real-time. This is achieved with minimal configuration and requires minimal end-user re-training. CONNtext helps ensure the maintenance staff works with the correct documentation each and every time, eliminating re-work and helping to ensure compliance with regulatory standards. The end result is the effective and efficient utilization of assets along with significantly reducing the risk of fines, penalties, regulatory agency enforced shut-down and catastrophic
failures.

If you are stressing out right now because you missed last weeks webinar demonstrating this innovative solution, don’t worry. Armedia has loaded the slides from the presentation HERE.

Most projects include building security, network security, and various other types of security policies which are generally inherited from the environment where the task is occurring and are fairly defined and stable.  Controlling access to the building, access to the network, access to files and folders, and general access to computing resources are all well established.  However, when we sit down and try to implement some form of security into the software we develop, it gets left out or deferred and needs to be added in at the last moment.  Why is it deferred? Well, how many requirements are really created around security?

Let’s throw a few examples out there:

• The system will only permit access to authorized users
• The authorized users will only be allowed to perform tasks they have been granted
• The authorized users will only be able to see the data they are allowed to work on
• The system will provide role and group based access controls
• The system will log all unauthorized access to data (is this security or logging –you decide)
• The system will log access to all data (Again, security or logging? Well, both)

These are very similar from project to project and pretty high level and very few, usually a dozen or so, but, without them in place, the system is essentially, non-functional.  Well, with the other functional requirements, what the user wants to see and do, which usually number in the hundreds, it’s easy to see why the security component gets little attention.  Except for the initial log-in, the users don’t really experience what is happening in the background, except for an odd warning about doing something they aren’t allowed to do.  A correctly implemented security model won’t even let the user know that features exist beyond what they are permitted to see.  What prevents them from seeing hidden features by glancing over their co-workers shoulder – well, that’s another issue.

So what happens when one of the most critical components of an application is not designed in from the onset? Besides chaos, a lot of redevelopment which is required to implement the missing feature, which leads to missing project deadlines and at worst not meeting implementation times. This is especially true for Fixed Firm Price (FFP) contracts where this can be disastrous to the bottom line, not to mention project failure – after all who will accept a system that cannot meet their basic requirements. Things are changing for the better, as I have seen projects now that have distinct security implementation team which interacts with the other development teams rather than being a side-attraction.

Naturally, for small scale web projects which are usually secured with 2-factor authentication (userid and password), the implementation is fairly simple and can be supported by the OS or a very simple database table.   If, however, you also need to control what the user can do (functionally) once authenticated, it starts becoming complex as you now have to maintain Access Control information for the user as well.  If you now further need to control what data they user can see, use, or modify, the security implementation gets even more complex.   Finally, if you need to implement CAC card integration, IP based authentication, CPU based authentication, or N-factor authentication (more than just a User ID and PWD, such as secure tokens, bio-metric, key-card …) , then additional complexities arise which need to be implemented in code or at the enterprise IT level.  Even now, we still haven’t addressed any encryption and data security requirements that could exist (ie. The system shall encrypt all personal data – does that just mean when it’s stored or also when transmitted??).  It is for this reason that security requirements must get high priority in any project where application, data, and system security are paramount, with the design engaged from the onset of the project.

The actual size of the security team will vary depending on the size of a project, but at least a single resource, with knowledge on all aspects of security (yes all, not just software), should be assigned as the single point of contact.  This person/team, throughout the project, must be involved intimately at the architectural level and will have the final say in any security testing scenarios.  By being involved at the architectural level, no design will be allowed to move forward until the security implementation has been vetted and approved.  Regardless of the security implementation, the primary goal is to confirm that all teams are compliant, which in essence translates to a compliant and secure application.  Whatever tests are needed to validate compliance should be defined during the design process as there is no better way to validate a system then to penetrate it by knowing its internals.  If you know how the security model is implemented and are still unable to compromise it, and then be default, the system is secure.  Open source systems fall into this category since all their code is accessible; everyone knows how to try to gain access, however, due to a well-implemented security model, they cannot.

At this point, we can keep going on about how imperative it is to make security design a high priority in any application design, or for that matter, any system design.  How would you like it if the car you bought didn’t have a lock or key to get it going?  Instead, I’ll just finish up with stressing that security is not a feature that can be put on the back-burner.  Everyone talks about it – you hear about cyber-security everywhere these days, but when it comes to the actual implementation, it gets compromised and inadequately implemented.  Considering that the raw power of computers is such that most systems can be compromised by simple attacks (such as brute force attacks), effort must be put into not just installing measures at the front gate, but beyond that as well to control losses if a breach were to occur.  It is also essential that management personnel understand this when planning a project to account for the level of effort it entails and to ensure that it is effectively budgeted for the entire project duration.

Now that we have addressed the issue of security in software system (and other systems), where do we go from there?  The best security is achieved by informing and teaching the user base, from the users up through the developers and managers.  I have covered a lot of items in this quick prelude to discussing security in information systems, but each should be followed with further details and training.

The situation, the project was with one of the leading product safety regulators in the world.  The international arm of the organization was leading an initiative to create a global information pool for product safety recall information in an effort to make product safety efforts across the world more coordinated and effective.  This would be a one stop, one shop view to “any recall – any where – any time” product safety recall information.

Armedia was asked to perform an initial assessment of what it would take a build a global recall information pool, build a roadmap for the process and structure the approach for the global consortium.  This was a pure play Information Technology (IT) strategy project where the focus was on creating an IT approach to meet a complex business situation.

What I loved about the project was the challenge of a highly unstructured business situation where the project sponsors understood the pain and knew the desirable outcome, but they had little understanding of what needed to be done.

Building an approach for an IT system in the area of product safety was a challenge, as I soon discovered.   Several factors contributed to the challenge, they included,  (a) plethora of legacy IT deployments, (b) changing data structures and data definitions over time, (c) different data structures and definitions across countries, and (d) project execution headwinds (Note: Our team ran into a situation of competing for attention amongst different priorities both within the organization and with 3^rd parties outside, in this case the consortium of product safety organizations from other countries).

Sound familiar?

So we walk into the situation not knowing all the pieces of the puzzle and the Armedia team immediately began an assessment of the situation.  Quickly the team structured the analysis into the following topical areas:

1. Strategic
2. Governance and Oversight
3. Functional Scope Definition
4. Usability, Data Search, and Discovery
5. Architecture
6. Deployment and Execution
7. Operations

Next came a deep dive into each area to develop specific recommendations and a roadmap at a granular level. Data categorizations, normalization and data definitions were all important areas of focus given the complexity of handling these items across different jurisdictions. I believe that our team’s recommendations around this area were excellent and well received by the international community, especially because our approach required minimal impact to current product safety operations, which was a key requirement by the sponsors.

We brought value in terms of providing structure and simplification for execution to what seemed at the outset to be a complex problem.  The Armedia report on “Considerations for Pursuing Global IT Interoperability for Publicly Available Product Recalls ” was published by the OECD (Organization of Economic Development) and has been accepted as the strategic guidance document by the international product safety working party set-up for the purpose of creating the global recall pool. The execution work on report recommendations has started and is currently underway.

This complex business issue was in need of a technology execution plan that was intentionally kept simple, and yet met the unique requirements of the customer. My team and myself guided our efforts in order to meet these criteria, and in the end the Armedia team successfully developed recommendations that provided both strategic and efficient solutions to this international IT challenge.

Closing this information gap is the idea behind the CONNtext solution, bridging the gap between IBM’s Maximo Asset Management and IBM’s FileNet Content Management

Different Lenses and Languages

Engineering and maintenance staff view the their asset worlds through different lenses and languages. When engineers are assigned responsibility for a modification, they are envisioning a future or even abstract state. Typically they think of the change in terms of a system or at a functional level. They need to know the design requirements for the facility, applicable rules and regulations or industry codes , standards and requirements such as licensing basis analyses, specifications and calculations.On the other hand, the maintenance staff view the assets as they exist today, at the discrete component level and beyond.

Engineering conceives the change and is responsible for sending the requirements and instructions for implementing the change in the form of output documents such as installation drawings, specifications and procedures. With a different view of the facility that is function and design driven, engineering is likely not providing the change information with the level of detail that enables the maintenance staff to readily implement and maintain on a component level. In their world, every minute detail about a device is important and must be accounted for in order to properly perform maintenance.

Different Tools

With physical assets and information assets constantly in change and each having their own distinct lifecycles phases, managed in different systems, managed by different sets of people with different lenses, and changed at different times change coordination is a challenge . Engineering typically works within an enterprise content management (ECM) system that captures and stores such documents as design drawings, specifications, calculations, analyses, load studies and other controlled documents.  Within the ECM system the index, search and retrieval function is based on an information classification system derived by the engineering community in terms of how they think and work. What you might not always know is “all” the relationships that exist and are required in order to enact a given change. This knowledge is reliant to some extent on the engineer’s individual knowledge of how things operate on the component level within the plant: the minutiae of the maintenance world.

The maintenance community on the other hand typically uses a physical asset management system that is more focused on work order management. The strength of this type of system is the ability to handle ad hoc processes that span multiple departments. This kind of system assists in long- and short-term planning, preventive, reactive, and condition-based maintenance, schedule management, resource optimization and key performance monitoring. Within this system, maintenance information has been classified by terminology that resonates within their daily operational world.

Framework To Bridge The Gap

Our CONNtext solution was designed to help bridge the gap between different views of the engineering and maintenance and the use of different information management systems by connecting IBM Maximo with IBM FileNet Content Management.

CONNtext operates within the existing user interfaces of Maximo and FileNet, meaning there is minimal user “retraining”. CONNtext employs a document classification filtering scheme that identifies the organizational documents pertinent to maintenance. Once identified, CONNtext is designed to help an organization further group those documents by maintenance terms to create views that enable automating the engineering to maintenance logic into a manageable process.

As a result, the Armedia CONNtext solution bridges the two worlds and users can now:

• Access engineering drawings and documents within IBM Maximo without having to learn a new system.
• Receive prompts to ensure that they are working with the most current version of the documents.
• Have searchable access to unstructured documents within IBM Maximo such as video, pictures, and documentation .
• Provide regulators with a complete work history of changes on the configuration of assets and their components.
• Identify loopholes in previously captured document relationships.
• Gain visibility into other changes and projects in process that are affecting the document that they are currently planning to change.

Armedia’s CONNtext solution has been validated by IBM under the Information Management, Industry Frameworks  and Ready for Tivoli programs.

Not surprising, the top 25 most dangerous programming errors contain some well known programming mistakes that have been with us for years (decades, in fact).  For example, the first error discussed in the report is SQL Injection.  Using
improperly escaped special characters in a SQL query, hackers can steal and/or highjack your data. Skeptical?  Ask Sony Pictures, PBS and MySQL.com, they were all victims of attack this year enabled by this common programming mistake.  It is
unfortunate, because with a little effort, this programming vulnerability can be easily mitigated.

Also, still in the top 5 is the classic Buffer Overflow problem. This mistake allows hackers to inject more information into a field or variable than it can handle.  The resulting “overflow” can contain malicious code and grant hackers access to your system, plant viral code, or simply crash your system.  Buffer overflows have been around for decades.  Too bad, since these too can
easily be corrected.

Other common mistakes include:  OS Command Injection, Cross-site Scripting, Hard Coded Credentials, Unrestricted File Uploads, bogus or flawed cryptography, and Open Redirects.  As detailed in the report, all of the errors are very simple to correct and prevent.  It would server everyone well — developers, testers, designers, managers and users — to be aware of
these errors, how to identify them, and most importantly, how to mitigate them.  Give it a read, it is well worth your time:  cwe.mitre.org/top25.

I’ve been in the software development business for 20 years.  Over the course of those years I have been involved in a lot of proposals, project plans, project re-plans, and estimating exercises.  I have used a variety of approaches and processes from very rigid, overly-documented approaches, to looser, Agile approaches to develop estimates.  One thing I have seen, regardless of the approach, is that project plans rarely reflect reality.  I have observed three frequent oversights when  developing estimates that always seem to bite project teams once reality meets the plan.

• Developers will spend 5% of their time every week on project management activities.  Time and budget are not usually allocated to developers to attend status meetings or company staff meetings, write input for the project manager’s weekly report, mentoring, or help with business development efforts, but it happens.  So, figure that 2 hours of every week will be consumed by activities of this type.
• Developers (especially those on the customer site) will spend another 5% of their time attending impromptu meetings,
  attending  ad hoc JAD design meetings, giving demos, supporting the project manager or customer, or dealing with customer drive-by meetings.
  Again, these are not activities easily anticipated or scheduled, but they occur all the time, and can negatively affect project performance.  Figure that 2 hours every week will be consumed by activities of this type.
• Developers new to a project need time to get up to speed on the project, the requirements, the environment, the tools, the processes and practices, the rhythm of development, and the project culture.  Don’t expect developers — even senior, seasoned developers — to be 100% productive from day 1.  Expect that it will take at least 40 hours for a developer to settle into the project  before he will be as productive as the rest of the team.  Schedule tasking accordingly.

I know it doesn’t seem like much, but over the course of a 5 week sprint, a team of 5 could lose 100 hours to these otherwise “invisible tasks”!  And, adding team member #6 will not immediately improve performance.

I mention these things because when I (and I suspect most project planners) sit down to estimate development times, we tend to estimate in a vacuum.  What I mean is, when asked how long it will take to develop Widget X or complete Requirement Y, we tend to give estimates that assume a perfect environment, the steady state of the universe, and that developers never get distracted by other project activities.  Or, that developers can be dropped into running projects and be 100% productive from the word “go”.

Hedging your task estimates by 10% and easing new developers into running projects can give your project plans a little buffer and more accurately reflect reality.  This advice will certainly not be popular with project managers or business development folk who continually strive for lower costs.  However, it may be to everyone’s advantage — yours and your customer’s — to produce a realistic project plan that can be met, as opposed to apologizing half way through the project that you have run out of resources for no ascertainable reasons.

Theoretically this means you can write ECM applications targeting SP 2010, Alfresco, and Documentum using only Chemistry (or some other CMIS application), the same as you can write database applications using only JDBC (and the vendor’s JDBC driver).  How well does it work in practice?

Actually, it seems to work pretty well, especially if your application needs can be expressed using the operations supported by CMIS… to some extent CMIS is a lowest common denominator.  The vendor’s specific tools (SharePoint Web Services, Alfresco Explorer and Share, DFC / DFS) certainly expose much more of the vendor’s unique functionality.  CMIS supports repository, navigation, object, versioning, multifiling, ACL, policy, discovery, and relationship services, via WSDL and REST bindings.

The CMIS standard defines the above services, and also defines bindings for WSDL, and REST (using the Atom protocol).  Apache Chemistry provides a unified API, such that you specify WSDL or REST when you connect to the repository, and then use the same Chemistry API either way.  Chemistry translates your API calls into the appropriate WSDL or REST requests.

For my project, I wanted to use the REST binding, since REST requests tend to be less verbose than WSDL, hence sending less traffic over the wire.  Also I have more experience with REST, since my project is using Spring MVC to publish REST services.

So we tried connecting to SP2010 using Chemistry’s REST bindings.  This was no trouble, as soon as we figured out the right URL to use (something like this: http://<sp2010_url>/_vti_bin/cmis/rest/<list_or_library_guid>?getRepositoryInfo).  Chemistry’s cookbook page was a big help.  Then we tried querying the repository, listing folders, listing folder contents, creating files, and retrieving files.  Everything worked great!  CMIS looked really awesome!

Then we tried checking out a file.  Wham!  We ran into a brick wall here.  SP2010 always returned an HTTP 400 “bad request”, no matter what we tried.  I traced the REST request Chemistry sent to SP2010, and used the excellent Firefox REST Client to send different versions of that request; no matter what, even when I sent invalid XML, I always got the same “bad request” response.

Time to work with Microsoft Support.  They reproduced the error, and are still working on the issue.  However, my support contact tried checking out over WSDL, and it worked fine!  I tried it myself; after jumping over a few hurdles to use Chemistry against SP2010 via WSDL, it worked fine!  So for now, we are stuck using the more-verbose WSDL protocol.  My MS support contact is still working with the REST support though.

As for the hurdles, Chemistry’s cookbook page came to the rescue again; the main issue is you have to download the WSDL from the SP2010 site yourself, and give Chemistry a file-based URL to the downloaded WSDL.  As far as I can tell, you can’t point Chemistry straight to SP2010′s WSDL; I always get a “401 Unauthorized” error.  It might be possible to use a normal HTTP client to download the WSDL locally, then point Chemistry to the dynamically-downloaded WSDL; I haven’t gotten that far yet.

I did make one change to Chemistry’s recipe; the cookbook page says to use Chemistry’s NTLM authentication module.  As far as I can tell, this requires the app server running your Chemistry-based application to run as a Windows domain user known to the SP2010 server.  But I want the app server to run on any Tomcat-supported OS.  Happily, it turns out you can use Chemistry’s standard authentication provider, and just provide a username and password like normal… obviously you would want to run such a connection over HTTPS!

Below is the code snippet I used to verify I could check out from SP2010 using CMIS (specifically Apache Chemistry) over WSDL: