Flipboard magazines

If you are interested in what I find interesting internet reads, have a look at my Flipboard magazines.

https://flipboard.com/profile/fschop

Posted in blogs, community, configuration management, music, software development | Tagged | Leave a comment

Is the configuration manager going to disappear?

The simple answer is: Yes, configuration managers are going to disappear!

The more comprehensive answer to this question is that configuration management is not going to disappear, but the configuration manager will be. We can compare it to the change of the crew in the cockpit of an airplane.

In the early days of aircraft, there was only a single pilot in the cockpit. With the growing need for air transportation of people and goods, the airplanes became bigger, requiring more advanced engines, more advanced hydraulics, electronics, aeronautics, navigation, communication and much more. So a second pilot was added. With the growing complexity of airplanes, a flight engineer was added with thorough technical knowledge of engines, electronics, hydraulics and dynamics; and with the growing complexity of the technology even a second flight engineer was added.
This trend was stopped when computers were introduced. Initially, the computers aided the engineers by replacing gauges and switches by screens and buttons, so one flight engineer was enough again. The next step was that computers not only relayed the information more concisely with better structure and overview, but computers were also put in control of complex systems like the engine, hydraulics and hydraulics. The user interface to the flight engineer was simplified and the responsibility of the engineer moved from decisions what to do and how to do it, to only what to do; the computer controlled the how-to-do-it. Currently, the flight engineer has disappeared completely.

Does that mean that flight engineering has disappeared too? No! Airplanes and flight control has become tremendously difficult. There are so many control processes running continuously and simultaneously that it is impossible for human beings to executed that. In fact, flying modern airplanes is not even possible anymore without computer systems.

Now, let’s go back to software and system development. Developing a control system like an airplane is complex, extremely complex! But developing a car is complex too, and even a “simple” device like a phone is very complex. A lot of people have to work together to develop a system and bring it to the market, each of them using a lot of information and producing a lot of information. The information is in constant flux; content is changing, relationships are changing, structure is changing, expectations and interpretations are changing constantly.

The traditional role of the configuration manager is to assure that the right data is available to the right people at the right time with the right status in the right format. To build a complex system requires a lot of work from a lot of people, requiring a lot of information to be used and produced. Adding to that a growing demand for speed, visibility, traceability, responsiveness to customer changes and a high level of quality, and collaborations between multiple projects and project teams in multiple sites at various locations and timezones… In other words configuration management is becoming more important than ever before.

In fact, similar to flying modern airplanes, developing modern systems is not even possible anymore without computer systems. And similar to the flight engineer, the configuration manager role is replaced by these computer systems, or Application Lifecycle Management (ALM) systems. So yes, configuration managers are disappearing. Project managers and quality managers can take control of configuration management through the ALM systems.

But something else is also happening: configuration management is disappearing as a separate discipline. Similar to saving and printing of documents in office application, configuration management is being embedded into the ALM applications that support the various engineering disciplines. For example, requirements management involves managing requirement which implies unique identifiers, versioning, storage and retrieval (including searching), baselining, status, delivery, and even branching and variant management. Some for testing management, portfolio management, roadmapping, and other disciplines. If we look at amazon, facebook, twitter, phones and tablets, cars, trains, airplanes, booking agencies, street lighting and security systems, healthcare and wellness systems, or even ALM systems, nowhere is configuration management a separate discipline. Isn’t it important then? Yes, it is so important that it is becoming a basic functionality of every system that manages information, like saving or printing in office applications.

So there we have it: configuration managers are disappearing and configuration management is disappearing as a separate discipline. Does that mean that I will be out of a job soon and many other CM-ers with me? No! Configuration managers will move into operational engineering or management disciplines (e.g. testing or project management), or into strategic process, business and development management disciplines (e.g. development manager, product manager), or into technical or managerial IT roles (e.g. tool expert, IT manager).

Posted in agile, complex systems, configuration management, excellence, large projects, software development, tools, tracking | Tagged , | Leave a comment

Software development in industry is lagging behind

I was watching a tv program on the distinction between fake and real. They covered the use of digital technologies to replicate art, or even create 3d animations about news or other realities. It made me think about system and software development in the embedded systems industry. Why are we developing the most advanced MR and CT scanners, the most advanced and intelligent lighting systems, the most advanced chip production or the most advanced printers, car navigation, coffee making machines, or even the most advanced airplanes, but still do it with technology from the previous century? Why are we applying the methods and the technology from the 1990ies to make products of today?
I often have a very hard time convincing my management to use digital technologies that is currently applies in companies like Google, Microsoft and even big blue IBM, and not only management. Also software and systems engineers find it often hard to accept collaboration technologies that is very common in our private lives and apply it in their professional life.
Why are so many people still reluctant to adopt agile methodologies, internet technologies like RESTful interfaces, or even collaboration technologies that commonly apply APIs supported by Google, Facebook, Twitter, Amazon, eBay or in products like smartphones and tables? Why are we using non-integrated software and system engineering and project management tools? Why waste so much effort on ignoring or customizing the functions of these tools, why waste effort on integrating these tools if there are integrated solutions available?
Apparently, wasting thousands of manhours is cheaper than spending a few thousand on improving the effectivity of the professionals. I just don’t understand how this is economical viable. Apparently, still too much money is payed for these systems that we can afford the waste in the innovation industry. Apparently is the competition also sleeping, wasting there time by using outdated technology. Apparently, customers have no alternative but to accept that we waste so much time and effort. Apparently, it is still profitable to waste precious innovation effort. Apparently, the large companies are still powerful enough to overpower the more advanced entrepreneurs. But for how long? When will we wake up that high tech innovation in large industry companies is seriously outdated?

Posted in complex systems, configuration management, large projects, software development, tools | Tagged | Leave a comment

Writing less, not more

You probably have noticed that I have exported my blog posts from Blogspot to here. And that I have not blogged very much lately, mainly because I do not finish and publish my posts. So, I am going to write less and publish it more often.

Posted in blogs | Leave a comment

Welcome to my new blog

This is my first post on my wordpress blog.

Posted in blogs | Tagged | Leave a comment

Jazz platform magazine

To collect articles on the IBM Rational Jazz platfrom, I am usingĀ  a Flipboard managzine. See http://flip.it/qwdPG

Posted in magazines, social media | Tagged , , , | 1 Comment

How to plan software as a configuration item

Yesterday I got a question from a colleague about configuration items. In our projects we use a deliverable list to identify which items are being delivered by the project and which are being received from outside the project. To help projects plan their configuration items we have defined a deliverable list template.

The deliverable list template lists documents like various types of requirement specs, design specs, test specs, manuals, training materials, etcetera. It also contains an single entry for Software. Now the question was:

What software deliverables (and receivables) should a project plan for?

Obviously, the deliverable list template does not give much clues. But we know that the software consist of components, some of which are received from other projects or third party suppliers – and possibly modified by the project – and some of which are created by the project. Then, how do you know which software deliverables the project is going to deliver?

The answer is that it depends on the agreement with the customer of the project. The requirements agreed with the customer state what he will get, in terms of functionality, performance, quality and deliverables. And these deliverables should be listed in the deliverable list. If the requirements don’t state the (software) deliverables, then apparently the customer does not care as a long as the functional and non-functional requirements are satisfied.
In that case, the architecture or high level design determines the software deliverables. Even more, the architecture determine which of the software components are reused from other projects or third party suppliers and which are created anew.

Okay, now that requirements and architecture/design define which software deliverables and receivables are applicable,

how do we plan in which release they are delivered?

For projects with a single (final) release, it is simple: everything is released and delivered at the end. For projects with multiple releases, like incremental development or iterative development, it is more complicated but still quite simple.

The total work of a project is divided in “work packages”, chunks of work that deliver a number of (possibly internal) deliverables. These work packages are assigned to a release and this way it is determined that the deliverables of those work packages are delivered at that release. More precisely, the deliverables are packed together as a baseline and the baseline is released.

Now in many software development organizations, the work packages are handled just like problem reports and change requests. They are registered in the change control tool/database, and assigned to people and releases (or iterations). We could call them “work items”; the list of work items planned for a release or iteration (in a release plan or iteration plan) determines which software deliverables are released. You could list those deliverables in the deliverable list, but it is more practical and more accurate to generate a report from the change control database listing the work packages, problem reports and change requests assigned to a particular release or iteration.

Posted in configuration management, identification, planning, software development, tracking | Tagged | 7 Comments