Business Analysis

Using requirements tool remotely.

2012-01-05T11:57:00.004-05:00

I have just realized that my last post here was back in May of last year... probably due to a combination of being busy with work I am enjoying, and not having any sudden urges to share something on the overall topic of business analysis, or IT in general.

So what's keeping me busy? an on-going project for a new system that has multiple stakeholders spread across the United States. What this means is that the project is using a requirements tool accessible over the net, so we have a meeting or two with stakeholders gathered in one place, followed by follow-up work done remotely using the tool, email and skype. That meant a lot less travel, and my "commute" was to walk down the upstairs hall in my house.

The interesting thing is the remote use of the tool. Maybe only a few years ago, being able to do this would have been seen as an amazing new capability; now we get annoyed if response time is less than immediate. It would seem that user expectations are still zooming ahead of tech capability.

Cascade #7 - Knowing too much about your business people's business...

2011-05-02T22:32:00.000-04:00

How much does IT need to know about the specific way their employer conducts business when competing in their industry? Again from experience, I suggest that very little or no such knowledge is needed going into a project. The cliché that “a little knowledge is a dangerous thing” applies here. If IT people know too much about the current business, they may be unconsciously constrained when devising new IT solutions by ‘the way things have always been done here.’ In extreme cases, this can lead to an IT staffer having the delusional belief that they know more about the business than the systems users and their management.

Do not fall victim to this belief. IT is about underlying hardware and infrastructure, and the information systems that run on them. The systems’ users and their management --- supported by all the strategies, policies, procedures and rules that define and control the business --- will know the specifics of their business better than IT; their jobs depend on it.

This is not to imply that all business users & management are omniscient, or that all businesses operate without duplications or errors, or that there are not things the business doesn’t know yet. In fact, effective use of IT can address many such issues in the operation of a business, but IT and IT people do this in support of the business; IT does not define the business.

So, know your business in order to support your business.

Comments, anyone?

David Wright
www.twitter.com/dwwright99

Cascade #6 - Projects change the business, so know the overall business first.

2011-04-27T12:42:00.000-04:00

Projects change the business, so know the overall business first.

A never-ending discussion in IT circles is about how much IT staffers need to know about the business that the information systems are supporting. It is high-lighted by every want-ad for an IT job that says previous experience in the employer’s industry is mandatory.

Is detailed industry knowledge and experience absolutely necessary for an IT job? No.

Can an IT staffer be effective with absolutely no knowledge of their employer’s industry? No.

As in many situations like this, the ‘Yes’ answer lies somewhere between the two extremes. Like a pendulum, the level of industry knowledge will vary across this spectrum, based on the specific organization, and by the particular IT role; e.g. Analysts need to know more than Programmers, and it justifiably argued that Testers need to know even more than Analysts.

So, some industry knowledge is required. I suggest from experience, however. that several week’s research on an industry is equivalent to several year’s work experience, as much of a person’s experience is rendered out-of-date by industry changes, or is too specific to the company they worked at. This is truer today than ever, as the ubiquitous Web makes information about almost anything available with a text string and few mouse clicks. (I especially like to look at vendors who offer packages that address any project I am working on, even for in-house development, it's a good way to see what the wider industry has been asking for.)

As a result, IT needs to know something about the industry going into a project, and the willingness to learn more as a project progresses.

Readers: Do you agree with me on this? I have had many conversations over the years with people who disagree; I have also had some business people say they get frustrated with "why does it take IT so long to learn my business?" What do your business people think about this?

Next in Cascade #7 - Knowing too much...

David Wright
www.twitter.com/dwwright99

Cascade #5 - There is always more work to be done than people to do it.

2011-04-25T20:46:00.000-04:00

There is always more work to be done than people to do it.

This principle summarizes the reality of virtually all organizations and activities, not just Information Systems delivery. It implies that a group within an organization charged with delivery of end results will a have a back-log of work not yet done. The existence of such a back-log is in itself not a problem, it reflects the desire of an organization to solve new problems and proactively improve itself; the problem arises when it grows perceptively in size from management’s perspective, and the length of time a change item sits on the back-log increases such that it can be measured in numbers of months or years.

So, we must accept that there will be a backlog; fully eliminating it would mean that the delivery group (like IT) becomes redundant, or that the overall organization has stagnated. What must be done is to embrace the back-log; it is IT’s input material and should be managed as such.

Question for Readers: How big is your backlog? Is it considered a problem? How do you select what to pick from the backlog to do next?

David Wright

www.about.me/dwwright99

Cascade #4 - Principles for improving IT Projects

2011-04-22T16:26:00.001-04:00

Like you, I have read my fair share of IT books, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems; the reverse is to document the new approach/method first and then describe what problems it fixes.

I am using a mixture of the two, in the context of a set of Principles that will put all the content of this book in context. This is not an original idea, I must admit, as many manifestos and proclamations have been used to introduce new ways of things; the Agile Manifesto is well known (http://agilemanifesto.org/ ) andI am a particular fan of the Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm). These and others like them lay out the basic reasons for their existence and the value they provide.

So what are these new IT principles I propose?

1 -There is always more work to be done than people to do it.

2 -Projects change the business, so know the overall business first.

3 -Use an overall Architecture to describe the business, before and after projects.

4 -Pick the right project(s) for the business.

5 -Once a project is started, finish it.

6 -Specialize – each member of a team assigned to a project should do what they do best for the length of that project.

7 -One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

8 -It’s the Deliverable (that matters), not the Task.

9 -Leave a record of what you have done, so the project will not miss you if you leave.

10 -Models are better than text.

11 -Partition large projects into 3 month phases, which is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

12 -Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks ( 2 developers ), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

13 -Given many medium to small software Deliverables, use architecture to manage and integrate the Deliverables into a complete system.

In Cascade #5 we will start looking at each Principle.

Cascade #3 - What can you do about all your IT Projects?

2011-04-21T11:23:00.001-04:00

So, what can you do?

You have to deliver on all those change requests, and finish those current projects so you can start new ones (there will always be new ones); this means accepting the things you can’t change and changing the things you can.

What can’t you change right now?

-The installed base of legacy systems.

-The backlog of change requests and bugs (even if you do manage to deal with a lot of these things, there will be new ones come along to take their place; that is job security).

-Senior management’s’ conflicting priorities for IT.

All of this is pent-up like rising waters behind a dam ready to burst. Something has to change, but you can’t just blow a hole in the dam, the result would be chaos.

So, what can you change (or at least start to change)?

-The structuring and management of the IT projects.

-Overall management of staff by skills/specialties.

-Effective allocation of staff to the projects.

What follows in the rest of this book-to-be is my prescription for this change, supported by some war stories, lessons learned, and lots of ideas to try. Every company has some unique aspects, so maybe not everything in this book will work for everyone, but I hope to give you enough ideas that some will work. My own fervent belief is that visible success with IT projects now may lead to softening/improvement of the things you can’t change right now.

I also really want to get your comments on what you think of the ideas I present, and I want to hear about what you do to deal with running multiple projects.

David Wright

www.about.me/dwwright99

Cascade #2 - "a project does not exist in a vacuum"

2011-04-20T15:31:00.002-04:00

From previous post
Projects are hard. Many years of doing projects, often unsuccessfully, has led the IT world to focus on how to do projects successfully. Project Management has emerged as a recognized discipline, and many smart people have provided many methods and methodologies for delivering IT solutions.

That is all well and good. What I have known since early in my career is that a project does not exist in a vacuum. Change does not happen in an orderly manner, one project at a time; it rushes at your company, lots of change happening all at once. That means many projects at the same time.

Do any of the following situations ring true for your company?

-A large portfolio of installed of information systems and underlying technology is being used, some of which is decades-old.

-A large back-log of requested changes to that installed base of systems has grown over time, overlaid with a long list of problems/bugs in the systems that the business is currently ‘working around’ until they ever get fixed.

-A large number of current projects are being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.

-The projects are being executed by a group of IT staff that has remained the same size in numbers, or has been reduced, while being charged with doing more work than ever. Each person is probably assigned to many of those current projects, juggling the work and trying to determine what they should really be working on.

-An “IT Strategy” has been developed that describes in glowing terms how the above problems will be remedied by moving to some new method or tool or one enterprise system… if the budget and resources can ever be freed up from fixing and changing the current systems.

-Senior management has a split-view of IT, that most of it is a waste of time and money, except for the work each manager wants for their own department/division.

I am writing this book in order to show you that the situation described above can change, and you had better get to it because it can get changed for you by outsourcing or other drastic options available to senior management.

Readers: To me this is the main problem, how many projects can you run at the same and get something done? There are lots of methods out there that tell you how to run one project well, but without any context of competing resources and priorities. I have been reading about Kanban lately, how it works for a project or an activity by limiting Work in Progress (WIP). Can Kanban work to manage multiple projects? I will keep reading but your feedback is, as always, most welcome.

In Cascade #3: "what can you do?"

Cascade #1 - Introduction to the Real World of IT Projects

2011-04-18T21:51:00.002-04:00

INTRODUCTION

I am writing this book for people who work at companies that have an ITdepartment to support their business. I realize this describes just about any company in business today, so I say this because there are many companies that are in the business of selling IT as their product or service. Many might say it makes those companies different from the rest, but I don’t think so; all companies need IT to support their sales & marketing, production, administration, HR, Accounting, and so on. So whether your company is making automobiles or serving hamburgers or providing investment advice, or selling software, it needs Information Technology; and to deliver that IT, your company uses Projects, lots of Projects.

Short of being a brand-new start-up, your company is already using a lot of information technology --- hardware, software, networks --- to run its business. Getting that technology implemented required a lot of work, likely organized as projects. As good as that technology was as implemented, and was used effectively for some time, some of it right now is not working, or needs to be changed to reflect change in your business; that means more projects.

I am not saying anything newsworthy here. After a number of decades since wide-spread use of IT began, your company’s IT department has become familiar with what a Project is: an effort with a clear beginning and end that changes the day-to-day Operations of a company; and as Scott Adam’s IT everyman Dilbert says, “Change is good. You go first.”

Projects are hard. Many years of doing projects, often unsuccessfully, has led the IT world to focus on how to do projects successfully. Project Management has emerged as a recognized discipline, and many smart people have provided many methods and methodologies for delivering IT solutions.

In Cascade #2: "a project does not exist in a vacuum"

David Wright
www.about.me/dwwright99

IT Project Cost-Benefit Analysis

2011-03-23T22:44:00.000-04:00

Assuming you got through the rough stuff of defining costs and benefits, the analysis should be simple. What you want to know is if the benefits of the project will exceed the costs, and by how much. Since costs and benefits may be spread over long periods of time, Present Values of these amounts are also usually calculated to compare the amounts in “today’s” dollars.

When I did my first Cost-Benefit Analysis for a major project, I had to work with a spreadsheet expert to do these calculations; now you can probably download something for free or a nominal fee that will do basic and advanced calculations. The key things these tools need is the cost and benefit dollar values, and the length of time of the analysis. The latter is usually defined by accounting standards at your company, and the most popular time periods used are three years and five years, often based around your company’s depreciation procedures/periods.

Given that, you can usually get calculations like:
• Break-Even Point, the point in time when the benefits realized exceed the project cost
• Various rate of return and yield values, like IRR.

These calculations may be used to determine if a project passes a funding hurdle; it’s not enough that a project makes money, it has to make more than investing the equivalent dollars of the project cost in securities or other investments.

After all this is done, a project can now proceed into the gating process to see if it has enough expected value to warrant its being initiated and carried out. Of course, if your analysis has determined already that the project does not have positive return or does not surpass the hurdle rate, you can stop now and move onto the next project idea. Determining that a project is not good for the business is just as valuable as finding those projects that are good for the business. Resources should not be wasted.

And that's it for now, comments welcome.

Defining the benefits of an IT project is a different issue from defining costs;

2011-03-09T22:16:00.002-05:00

...continuing from the previous post...

Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. However, benefits are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.

In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.

In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived it could lead to lay-offs, this could kill a project because you almost always need those people as the business experts for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.

However, automation of manual work as a benefit could usually be quantified in dollars in potential saved salary costs. The problem today, however, is that all the obvious automation projects have probably already been carried out at your company. This leaves smaller or less obvious cost-cutting projects (taking orders on-line saves on paper costs...whoopee!), or, projects that are expected to increase revenue/income.

The question becomes: how much will such a project contribute to increased sales of products and/or services? This is difficult to predict, and most business people are leery of attempting to do so. Just like IT Project teams are held to a project estimate or be considered late/costly, business people who estimate revenue increases can be held to task if it is perceived that the expected increase did not materialize. An interesting corollary development is the increase in the number of companies that are evaluating projects some time after they complete (six months or so) to see if the promised benefits have been realized. This can make business people even more wary of putting their names to what is and should be treated as an estimate.

In the end, however, some dollar value of benefits needs to be proposed and agreed to, if a cost-benefit analysis is to be performed. All I can say here is that, like all estimates, stating your assumptions and having them agreed to as the basis of your estimate is crucial. If reality proves that one or more assumptions turn out to false, then everyone involved in the project shares responsibility.

Next time: Cost - Benefit Analysis

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf

what projects does the Enterprise consider to be most valuable?

2011-03-02T23:19:00.002-05:00

...continuing from the previous post...

The key question then is: what projects does the Enterprise consider to be most valuable? And the follow-up: how does it determine the value of any one project, so it can be evaluated against ‘competing’ projects?

In private enterprise, the single common goal is sustained profitably , through a varying combination of revenue increases and cost reductions. Projects are often used to change how a company operates in the expectation that such change will deliver the desired revenue increase or cost reduction, and deliver it such that the value of the changes is not exceeded by the cost of the project itself.

So, we have two aspects of a project that will usually be used to determine its value:

1) Its impact on revenue or costs of the enterprise, commonly known as Benefits.

2) The Costs of carrying out the project (which some refer to as the ‘investment’)

Given these two dollar numbers, which is what they should always boil down to, you can then use them in one or more forms of what is commonly called a ‘Cost-Benefit Analysis’. However, neither number just appears out of thin air, and any numbers you do come up with will never be exact, because estimating is involved

Lets’ start with Costs (it’s easier than Benefits, at least); essentially you need to define what resources, services and purchases will be needed when executing a project.

IT Project Costs

A typical IT project will involve IT people resources, of course; analysts, designers, programmers, testers, trainers, etc... The titles may be different at your company, but the people will be performing these roles. The question, of course, is how much of the valuable time of these people will be needed, and how much that does that time cost? This is when the estimating begins.

My experience with estimating has led to always determining how accurate an estimate needs to be. When using cost estimates as part of a gating process, I find a reasonably supported estimate done in a short time will suffice. I have heard an initial estimating being referred to as “t-shirt sizing”; is it small or medium or large or extra-large, etc. Even this needs some context for a company, usually by classifying past project actual efforts the same way.

This supports the simple approach of “Is this new Project X the same size as a previous project we have carried out?” Assuming your company has kept the metrics about previous projects, and that is a big assumption, you can then extrapolate the size and cost of any similar new projects.

True, some one has to lay it on the line and decide if a new project is reasonably similar to previous projects, and the person doing that should probably define some assumptions about why they believe so. This allows the decision makers to agree with or challenge the assumptions as needed, until all are agreed on the assumptions and accept the resulting estimate.

If you have no metrics history to use, you may need to do some project planning to define the tasks likely to be carried out. Again, a whole other big discipline exists for project planning and management, and use of techniques of like Work Break-Down Structures (WBS).

The only thing I emphasize in this approach is that as much as possible, people who would do the work should help in defining the necessary tasks, and then they most certainly should do the estimating of effort (usually in hours or days) of those tasks. They know best what will be needed, and will make sure they are happy with the estimate because they will likely have to work to that estimate when the project starts.

In the end you will have a number of effort hours or days, and then you need an accepted price for an hour or day. Some shops will use a flat rate for all hours, while others will group the hours by role or seniority to get a range of rates. In either case, you multiply the hours/days by the price(s) and you have a cost. Other costs may be involved as well, especially one-time purchases of equipment or software needed by a project.

To go along with this cost, you will need an estimate of elapsed time for the project to execute and finish, because most benefits will not be realized until a project is over, and (later on) you will want to compute a present-value of future costs. More assumptions are needed; how many people will be assigned, what work can be done in parallel, etc. If you have used a project planning approach, you will have the advantage of defining many of these things already and will have come up with a project duration along with the project effort.

That's Costs... next time : Benefits

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf

Who"owns" IT Projects?

2011-02-25T23:28:00.002-05:00

Who “owns” IT Projects?

I said I would post on this topic, but it is really more of a history piece. Here is an excerpt from my book “Cascade”:

CHAPTER FOUR– Pick the Right Projects for the Business
…
Early computer projects were run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well; so, the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.

So, projects proceeded into more complicated areas of the business, and they started to break down, some failed, and now Management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable); and how did they all get started anyway?

(… because the business looks around and sees) a lot of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.

(This has to change to get these projects under control, including a new awareness…)

That awareness should include:

1) A recognition that IT projects do not belong to IT, they belong to the Enterprise as a whole, even if various non-IT parts of the Enterprise are assigned responsibility for some sub-set of projects.

2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the Enterprise’s Strategic Plan.

3) The realization that dozens or more project ideas may be in play at any one time, but the average Enterprise does not have the resources to do them all; it must pick from the candidates which projects will get to proceed, and it must continue to do this as current projects are completed and resources are freed up.

It all boils down to best use of limited resources. The term that has emerged to describe all this is Project Governance. The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.

It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development (commonly called Construction). As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure as described above. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the Enterprise.

The key question then is: what projects does the Enterprise consider to be most valuable? (That’s for next time.)

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf

Maybe it is time to define "customer" in IT Projects

2011-02-23T00:38:00.003-05:00

IT projects and methods seem to big on the word "customer" these days...

Common definitions of:

customer - one that purchases a commodity or service

purchases - the acquisition of something for payment

So let me propose this definition: unless you are selling software as a product for real money, your IT project does not have any customers.

I have spent my career working on IT projects for companies that need systems to run their business more effectively/profitably.I have worked with many a sponsor, and many business people who will use the systems, but none of them paid me directly for doing so; we all worked for the same organization, with job titles and salaries to go with those titles.

Most of these organizations used some kind of budgeting/cost allocation to align the cost of the systems to the revenues of the parts of the company that would use the systems. However, this is not purchasing, it is management.

However, some of these organizations used a definition of an internal form of exchange - 'gray money' or better known as "funny money" - to not only allocate cost but to measure managers' effectiveness and often their bonuses. The main company I saw this at is no longer an independent organization, as it fell on hard times and was acquired/assimilated by a more successful company. One of the reasons was management choices like the following:
Two similar business units (same product, different market) needed new systems. One (Unit A) got a head start and developed a functional system. The other (Unit B) saw the system and said "we could use that too". Unit A asked for payment in funny money of half the cost of development. Unit B balked, and spent a lesser amount of real money to buy a package, because that looked better on Unit B's cost reporting... real money spent that should not have been necessary.

So, within an organization, there are no customers and there are no purchases; acting like there is can be detrimental to the organization as a whole.

But we are talking about customers of IT projects, surely that can't be the same; yes it is. Call someone a customer and they will act in their own best interest, however that is measured, and with disregard for the success of the whole organization.

IT projects should not have buyers and sellers; they should have teams of business and IT people working together to reach a common goal. So you see, the definition of "customer" in an IT project is that there isn't one.

BPM: It’s About Managing Change (Fourth in a Series) - Rules, Rules, Everywhere Rules....

2010-12-30T11:00:00.000-05:00

So, from even the list of examples in my previous post, it would appear that rules are everywhere in a business, and this is in fact a testament to the value of managing business rules effectively. For the most part, though, they can be categorized in relation to how they impact the other two main components of information systems: data and process.

For your data needs, business rules help with conditional relationships and data values. Consider the example of when an order qualifies for a discount. When an information system is used to create a new order, the database schema would have informed the programmer that certain data attributes are needed to create a complete and correct order — like item and discount — and what values those data attributes are allowed to be for the order to be considered valid for the business. However, a database schema cannot document and enforce rules about values of a field that are dependent on the values of other fields; those are rules. Further, if an order needs to have an association with a credit authorization when payment is by credit card, that is a conditional data relationship that cannot be described in a database schema; it is a rule.

For your process needs, business rules are critical for the decisions made in a process. Basic implementations of a BPMS will automate the flow of activities but will stop executing and exit to a user prompt when it reaches a decision point, the diamond in the diagram. A person needs to respond to the prompt and indicate which path the process should follow next. This is better than not having a BPMS, but it is not yet an ideal implementation.

Why? Consider that most decisions made in a business are consistent and ongoing applications of rules (e.g., does the customer qualify for a discount on this order?) and are made many, many times a day. In these situations, the person is looking up the rules in a manual or, worse, applying them from memory, which we all know can be faulty in even the best people. This is where BRM has its biggest impact. It can elicit those common rules out of the manuals and memories and get them into a BRMS, and then business processes will flow uninterrupted until a new situation arises. That is when a person is really needed, and once the new situation is understood, it too can be defined as a rule and added to the BRMS.

Next Time: A Model for Business Operations - Process , Data and Rules

BPM: It’s About Managing Change (Third in a Series) -Supporting Business Rules; will Brute Force work?

2010-12-29T15:42:00.000-05:00

"....systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially."

Many organizations tried to solve this problem with brute force: adding more resources, running more projects, outsourcing what could not be done internally. Other (fewer) organizations saw the diminishing returns that approach produced and started evaluating the problem laterally. They determined that data definition and then process definition captured a lot of what business is about, and automating their management was of benefit, but neither included "the set of rules that determine how a business operates — that is, rules that prevent, cause, or suggest things to happen." ("Defining Business Rules — What Are They Really? Final Report, Revision 1.3." Business Rules Group, July 2000)

These organizations realized that just as data needed a DBMS, and process needed a BPMS, business rules need business rules management (BRM) and a system to support it: a BRMS. I’m not talking about codelike procedures; these are human-readable rules that can also be implemented as declarative statements, such as:

- A customer can place an order, only if they are 18 years or older.
-A customer can place an order on credit, only if their credit rating is "good" or "excellent."
-The insurance coverage for a 10-year term life insurance policy must be $50,000 or higher.
- Premiums paid by direct debit must have a monthly payment frequency.
- A credit application greater than $1,000,000 must be approved by the manager of underwriting.
-An order is fulfilled, only if the ordered items are in stock.

As declarative statements, business rules need to be automated irrespective of any procedural order. All rules are applicable to the business at any time, not according to any order specified in a coded program. The structure of the rule statements must meet the two primary needs: readability and execution. The means of accomplishing this, fortunately, have already been developed and standardized for us through the OMG and its "Semantics of Business Vocabulary and BusinessRules (SBVR), Version 1.0.". The above examples meet the requirements of this standard and would be executable by any BRMS that supports it; so now your rules are don't have to be frozen in code.

Next time: Rules, Rules, Everywhere Rules....

BPM: It’s About Managing Change (Second in a Series) - Things change, but are they really different?

2010-12-22T23:22:00.002-05:00

We can agree that business processes change a lot, but a little analysis of the nature of these changes reveals that they are of the same type(s): activities are added or removed, or the order of the activities is rearranged, or the criteria used to make decisions changes. This is what business process management systems (BPMSs) were created for: defining activities, decisions, and their order in a business process, with the ability to change the process in common ways without requiring an IT project. The power of a BPMS stems from identifying these stable patterns of change and supporting them with structures — activities, decisions, and the definition of their order — that allow for change.

THE DATABASE ANALOGY

To illustrate the point of stable change, consider database management systems (DBMSs) as an analogy. A database embodies a model/structure of an organization’s ongoing data needs, patterns of entities/objects, and their relationships — what database analysts know as the "schema." With this stable structure, new occurrences of data are added as needed through application systems; the need to add new data item definitions to a database is very infrequent, occurring only if the business of the organization changes significantly or the organization enters a new business.

Further, databases are not just containers; they are rule enforcers.The optionality and cardinality defined for relationships are rules, such as "an order must have at least one item being ordered but can have many items being ordered as well." This is what any business person will tell you is true about an order, so a database can be used to enforce these rules.

This enforcement is good, but it is also limited. Database rules, especially optionality, are cut and dried; they cannot implement conditional situations, such as "a relationship is mandatory only when x=y." For example, an order must be related to a credit approval if the payment method is credit card. When the business presented this kind of situation to IT, the data edit was born. As you might expect by this point, this response was implemented in code and used primarily when a new occurrence of something, such as an order, is created by an application system. It has also been known as the input edit, the screen edit, and the field edit. A special case is the cross-edit, where the value of one data attribute is constrained by the values of another. For example, a discount for an order can be greater than 25% only if a certain type of item is ordered.

This solution using code has caused even more problems than the examples described previously, because "data edits" are a technical IT term for business rules, and what I have learned is that business rules change even more often than the business processes that use them for guidance. Working in insurance, and then lending, I have often seen code that implemented underwriting business rules to automate decision making, only to then see the business rules change enough that the results produced by the code were no longer valid and had to be extended by manual workarounds. So the systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially.

Next Time: Supporting Business Rules; will Brute Force work?

BPM: It's About Managing Change (First in a Series) - Why are Business Processes frozen?

2010-12-21T15:03:00.000-05:00

Despite many things written and said about businessprocess management (BPM), it is really one thing for certain: an automation improvement that supports change management.

WHY ARE BUSINESS PROCESSES FROZEN?

Business processes are the lifeblood of an enterprise, moving and shifting to respond to the ever-changing business environment. They are sets of activities in an organization that are performed in response to a trigger— an external stimulus, an internal state change, a point in time that has been reached — to provide a desired result in response to that trigger.

The nature of business processes lends itself to diagramming them in some manner. You can present the starting and end points as circles, all the activities as boxes, decision points as diamond shapes, with arrowed lines connecting all of the above (swim lanes optional). What all this drawing means is that, given sufficient effort, it is possible to fully define a process as it exists at a point in time.

Why the emphasis on a point in time? Consider how most businesses’ processes and activities were automated for the first time: the process was defined, and programmers designed and coded programs for a system that executes the activities. On the day the system is implemented, and for some period of time afterward, it does what it was designed to do, and the business performs its processes using that system. No one is aware that the business process is now frozen in time.

Fairly soon, however, the business decides to change its process somewhat to deal with new problems or opportunities. The system does not support this changed process, so a project is needed to open the system, make the changes (correctly), test the changes, and implement the new programs for the system. This takes time. The business process essentially must be thawed out, redirected, and then refrozen.

By the time this effort is completed, however, the business has more changes lined up. Here we see the arrival of the two curses of information systems: (1) the backlog, and (2) the workaround.

Next time: Things change, but are they really different?

I am ranting about Agile again...

2010-06-25T00:05:00.003-04:00

...and I am not proud of myself. A couple of years ago I worked myself to a space where if it worked for you, what ever method you liked, my feeling was "power to you". Even among Agile proponents there were some reasonable voices who decried the prevailing "If it isn't Agile, it's Crap!" hysteria.

But I obviously keep tuned to writings and postings about Business Analysis and Requirements, and some of the stuff that used to annoy me is seeping back into the mainstream, basically that "we have to do all this hard Agile stuff because you can never get good requirements before you start coding."

A lot of it is couched in seemingly sincere attempts to find a place in Agile, in Scrum particularly, for that poor soul, the Business Analyst. Even actually sincere attempts to do this carry the implied the subtext that "we have to find something for the BA to do, because he could never manage to do what he was supposed to do, get the requirements done first.... we would not want to see him/her lose their job..." So, let's make him the Product Manager, especially since the real business product manager can't be bothered to get involved. (Corollary note: i see all the time that developers want to work more directly with business users, but I can't say as I see business users saying the same thing about developers.)

So, I try ignore this and carry on, but then I end up commenting on posts like
http://www.batimes.com/articles/the-business-analyst-facilitator-role-in-an-agile-software-development-team.html

Maybe things will calm down again and some moderation will prevail... I hope so.

Cutter IT Journal: my article on BPM

2010-06-10T17:51:00.001-04:00

Hi all,

Have a look at http://www.cutter.com/offers/bpmalternative.html to see the May issue of the Cutter IT Journal, with my article on BPM leading off.

Another attempt to understand Business Analysts

2010-05-29T00:09:00.002-04:00

I am sure Ann Hall over at itbusinessedge.com is a nice person, and I appreciate her interest in what Business Analysts are or do, but she is not helping by quoting people who say my real key skill is customer service... have a look at http://www.itbusinessedge.com/cm/blogs/all/does-a-business-analysts-background-matter/?cs=41432#cf

Conversations

2010-05-27T17:31:00.001-04:00

Linked In is a pretty good place for conversations these days, here is one on "Should the BA be a SME?" at http://bit.ly/9VhruQ (No fair guessing my view before reading it...)

Blogger's Block

2010-05-20T00:22:00.002-04:00

I seem to be posting less often these days. and if no one else has coined the term, I will call it "Blogger's Block."

I have said before that when blogging first appeared, I paid it no mind as it seemed that they were all (mostly young) people's public diaries; eventually I saw that there were more and more blogs that were about topics of interest, the main ones for me being work-related on business analysis and methodologies and such. One of these must have been on blogger.com, which basically said I could have a blog too, just sign up...so I did. This was about the same time that after attending BA and IT conferences for many years, I realized I had things to say that were just as meaningful as the speakers whose sessions I was attending.

So, the dam was busted, and looking back, I am a bit amazed at just how much I wanted to communicate to anyone who might stumble upon this site. Often it was things I wanted to say in my work environment, but couldn't because my boss would not have liked it or it would have just fallen on deaf ears.

So over 20 years of thoughts and experiences just came pouring out, but the well is drying up. Perhaps it may be that what I am doing now as a consultant lets me speak more freely, along with the fact that I really like what I do now.

So, what to do about this? anything? does it matter? Should I start the "Best of David Wright's Business Analysis Blog", essentially re-run old posts that might still be relevant? or just let it fade away, it's purpose having been served? Stay tuned, anything could happen...

Agile is Fragile

2010-04-24T22:38:00.000-04:00

Recent experience at a client showed me that Agile can be successful for a project, but maintaining a level of success across projects and organizations is difficult.The client had one team using Scrum that was delivering sucessfully, but several others that were not.

A manager of one of these other teams told me that their biggest problem was turnover in the Product Owner role; a business person would take on the role, get better and betterat it, then change jobs. The team would have to acquire a new person and start from scratch again.
The other most common problems were scope creep, and excessive change during dev sprints in a project. To me, these are another sign that the Product Owner role was not being performed well. Overall, the discipline needed to make Scrum effective was not being practiced.

The client's response to these problems was to focus on a process for requirements definition, to have stable and clear requirements available for use by a dev team, irrespective of the development process that team may use. Yes, this can be seen as a step backward from an Agile point of view, but what else could the client do?

As a consultant involved in implementing the new requirements process, I have to acknowledge that some readers would say I am biased against Agile/Scrum. What I am biased against is any process that is not working. The client's original use of Scrum is certainly before my time, but it can be safe to assume that it was done for good reasons, one of them likely being that up-front requirements was not working for them.

Over time, the above agile fragilities became apparent and something needed to be done. Rather than try to improve their use of Scrum, the client looked back to its original problems and determined that ifScrum did not solve their requirements problems, what else might? ...leading to me coming to this client to do a Requirements Process Improvement program.

That does leave the one team that is successful with Scrum; how can a Requirements Process fit into what they do? What their team leader and I have worked out together is that functional requirement statements (e.g. The system must have the ability to create an Order) can be matched to User Stories. A good set of Requirements helps deffne a much better and stable Product Backlog to use going forward with Scrum.

In the end, it is about the process, whatever it is, that works for an organization, delivers successful results, is repeatable, and can be learned by others with the same results; anything else causes more problems than it solves.

A Year on Twitter

2010-03-25T21:09:00.002-04:00

I was a late-comer to twitter, one of the horde that joined in 2009. I was in a similar fashion a late-comer to blogs. When blogging started picking up, it was mostly painted as individuals exposing the equivalent of personal diary entries to the whole world. This was not something I had any interest in, but it eventually became apparent that people were blogging about topics of interest, including business and systems and methods and so on. Many of these people were authors of note on topics of direct interest to me. After seeing some of these, and realizing how easy it was, I started this very blog. It may or may not have have reached an audience of any size or import, but I have enjoyed it as an outlet for my thoughts and opinions on Business Analysis.

Then came Twitter, also first painted as people's random thoughts or status, the famous "what I just had for lunch" type of tweets; as before,this did not interest me. Then at the beginning of 2009, I saw some articles (and probably blog posts!) about how this odd Twitter thing might actually be useful, to busineses for example. I also saw on blogs I read the appearance of "follow me on Twitter" announcements. So I joined and started following some of these people. I have a been long-time user of Google Alerts to find things of interest to me, but I found I was getting links to things from Twitter that Google didn't pick up. It is apparent that following someone because of one interest may lead to other unexpected content. This is what I have found Twitter most useful for. People will tweet when they have a new blog post, and then tweet links to other things of interest.

I then discovered all the Twitter apps that tell you how influential you are and such. One thing they usually consider is if you are engaging with other tweeters in conversations, as opposed to just tweeting your own stuff all the time. I would say that of about the 300 people I follow, I do have conversations with about a dozen or so people, mainly other BAs and Systems folks.

The interesting thing is when you have a (probably one time) conversation with a more famous person. They may be tweet somethinng or even ask a question, which spurs me to reply. Most times the replies are not returned, but once in a while they are, which is oddly gratifying; recent folks I have conversed with are comedienne Elayne Boosler, and Peter Travers, movie critic at Rolling Stone. Why does this seem special? I guess it is like getting 15 seconds of fame (a whole 15 minutes of fame being so 20th century).

After a year, I guess what may be most surprising to me is that I have acquired over 500 followers... I mean, I think I have some interesting or funny things to say on occasion, and I do my share of re-tweeting, and I do tweet when I posted on this blog, or over at ITWorld Canada. Yet it does astound me that this has led to me to slowly but surely getting more and more followers. I don't expect I will ever have thousands and thousands, but actually getting into the hundreds was something I wasn't expecting a year ago.

Sure, I have used various apps to analyze who is following me. It is true that many are automated follows, like when I tweeted about the Toronto Blue Jays one day, their twitter account started following me. Then their is always the occasional email about a new follower who turns out to have been suspended for "suspicious activity". But there are some people following me I just don't understand, like all those people who describe themselves as on-line marketing experts.

However, there remains a group of people that number in the hundreds who found me somehow and decided "yeah, I will follow this guy." So, if you fair reader are one of those people, thanks a lot.

Great product for requirements sessions, why is it so hard to find?

2010-03-12T10:57:00.003-05:00

The product is whiteboard sheets. They come on a roll, you rip one off and stick it to almost any wall surface, and it clings. You then write on it like a whiteboard, then the ink will dry permanently after a few minutes.

I and my peers use them in requirements discovery sessions. The walls fill up over time, so you can look at anything you have produced. The fact that the ink dries allows you to take them away and use them later for writing up results, and to keep as a record.

These are not a common item. Each new client we work with invariably says they have never seen them before. Our organization gets them from a supplier in Germany, the product packaging says Leitz.

Office Depot shows up as a source when you do a web search, and Amazon too, but actually finding them on their sites is difficult. Right now Amazon says they don't have any and don't know when they will.

If you look for them, don't confuse them with "instant whiteboards"; these are thick sheets that cling to a wall, but are erasable at any time, like a hard whiteboard.

But finding them is worth the effort, and I hope more people using them will make them easier to find.

Shoud use cases specify system solution?

2010-02-25T18:06:00.002-05:00

Another new discussion : Shoud use cases specify system solution? Always good to make sure what seems obvious to us is clear to others.

Discussion: What do we do about IT Project Requirements problems

2010-02-22T12:50:00.003-05:00

A discussion from the IIBA group on linkedin...

http://bit.ly/crfhTr

Deep in many discussions.... 10 Signs that you're really "Wagile"

2010-02-11T18:58:00.003-05:00

I have not posted here much lately because I have been out there engaging in discussions on business analysis and requirements topics at various sites.

So, here is the link to a good one called "10 Signs that you're really "Wagile""

at http://bit.ly/aIWBmB

(I am not sure when I post this if the link will be usable, but a search on the topic should find it...)

Thoughts on Consulting #3 - you get access

2010-02-02T20:34:00.003-05:00

Sort of a corollary to #2... When I am engaged to work with a client, all of their people you need involved tend to show up when you need them. Sure, I represent a specific expense that no one wants to be seen as wasting, but it can be more that. The seniority level of the people is high as well, so you know if you need a decision made, the decision maker is in the room, no one has to go off to get that decision from someone else.

I am not saying this is fair or anything, it's just the way it is, so I enjoy it as it comes.

Thoughts on Consulting #2 - if the Consultant says it, it must be right...

2010-01-28T23:39:00.001-05:00

Thirty years in IT, 28 not as a consultant.

If you work in IT at a typical company, you may have had some good ideas, some recommendations, but they were not given their due by management, and you wondered what it would take to make some meaningful change... then an outside consultant comes in, and says basically the same thing, and management pays attention and says "that's great, let's do that!", and you sit there saying "but that's what I said...", or you keep your peace and help to make the change.

That's just the way things go sometimes, I have no great insight to offer you on this. Management laid out large amounts of money to get the consultant to come in, so it is real hard for them to say "we knew that already" or even "that sounds familiar...".

So, have I been part of something like this since I became a consultant? As Mr Bean said in in his movie "...not that I am aware of." I would like to think I would recognize it when I meet those employees, and try to work with them to increase the chances of success. So far, I have met people who agree on what the problem is I have come on to address, and want to help, but have not seen a case where someone already had figured out the solution before and had been ignored. The thing is, that could actually be true but I may never know it. So, I can only do the best job I can and leave everyone as happy as I can make them.

And if you are are an employee with good ideas not getting their due, maybe its time to start consulting!

Thoughts on being a consultant...

2010-01-27T19:47:00.001-05:00

Since 1979, I was a regular IT employee of the organizations I joined and left up until early 2008. “Consulting” to others in the organization was something I started doing as I gained useful knowledge and experience (while trying to dump anything un-useful on an on-going basis…like Data Flow Diagrams), often within a staff unit that did R&D. I drove the implementation of new methodologies at one company, for example, to the point of defining and delivering training to other employees.

Of course, I also worked with external consultants now and then; most often they were people with experience in a method or tool the company was adopting, to accelerate that adoption. It is a slightly unusual that I never worked with out-sourced resources over those years; the employer I spent the most time with had been an early example of outsourcing their computer operations to a subsidiary, and then selling the excess capacity to other companies. But, the project and development staff stayed within the main IT organization to be ‘with the business’ and that included me. (This does not include the many contractors I knew who came on-site to work; to me they were peers who just had a different employment model.)

Back when outsourcing got going, it was all about the impact on programmers and related tech roles. As a Business Analyst, I was comforted by the initial assertions by various gurus and pundits that Business Analysts could never be out-sourced, because we need to be near the business people to do our jobs.

However, as I gained experience, learned a lot and (hopefully) got better at what I do, it became apparent to me that while Business Analysis could not be outsourced to other continents, it is a discipline that could be done by external resources. They would come in for a focused period of analysis and deliver a set of requirements that could indeed be understood by the business and be of use as input to design and development. I knew this because even as an employee, because more and more I would do analysis for one project, then move on to the next one while the first project moved into development. I would be available to that development team as needed for questions or changes, but this only required a small part of my time. So, it was not necessary for a Business Analyst to stay with a project until its conclusion, there was no more Business Analysis to do to keep them fully engaged. (Now, if a BA also manages the project, or does testing, that’s a different thing, and I avoided both of those tasks most of the time.)

Being somewhat of an optimist, I thought this could be an opportunity rather than a threat, and I started looking at consulting companies as an option for a career change. This ‘looking’ lasted a while, as the majority of consulting companies did not do business analysis; lots of design and coding, but no analysis. I did not want to branch out as an independent consultant, or even a straight contractor, a little too risky.

However, I and the right consulting company found each other in 2008. It took only a few weeks before I joined up.

Hmmm, this has been a lot of lead-up to what my thoughts are now; perhaps they will help someone else who is heading down the same path as I was.

So, thought #1, concerning Travel: the typical week is fly out to a client’s location on Sunday evening, work 5 days, return home Friday evening. I had never minded doing business travel in the past, but it was not frequent, so the concern is what will traveling all the time do to you; will you burn out in some way?

Two years in, the travel is OK. It’s not glamorous; all I see is airports, hotels and client offices. Only one time have I stayed over at the client location to do a little sightseeing; that is not the same as a vacation with family, though, so I don’t expect to do it again soon.

Speaking of family, I have three sons, and the youngest was 20 when I started this. I don’t think this could have worked when they were growing up, it would not have been fair to them or their mother, so the timing has worked out.

Benefits? A lot of hotel points that did cover lodging for our last vacation. Most of my flying is short-haul on the east coast, so the frequent flier points are building slowly. Don’t believe I will reach the million mile level anytime soon…

More thoughts to come in future posts….

Memories of IT - 2003-2006 - Business Rules, and blogging

2009-12-29T14:05:00.003-05:00

So, I was back in the trenches. Most of the projects were enhancements of existing systems, while building up to a replacement of the main loan application processing system. I did a little project management along with Business Analysis on smaller projects.

One thing I did get some time to research was Business Rules, starting with the Business Rules Manifesto, and reading of proponents like Ron Ross. I worked on getting Business Rules defined explicitly in the company's requirements documents, which went well; I also attended 2 Business Rule Forum conferences, and did a track session at one of them on our use of rules in requirements.

I did the track session because it reached the point where I had been to enough conferences over the years that I thought I had something I could offer, rather than just attend. The conference organizers seemed to agree, as I did a few other Business Analyst World conferences on how I was doing requirements work.

Also, I had been ignoring the rise of blogs, until it became apparent to me at some point that it wasn't just for young people sharing their feelings and thoughts on movies; blogs on business and IT topics were emerging, and again I saw them and thought "I can do this", so I started this blog and did one over on IT Toolbox for a while. Being a Business Analyst can mean writing a lot, and I have found the blog a great outlet for writing that is not specifically for a project. I highly recommend it...

Memories of IT - 2002 - DHL was fun while it lasted...

2009-12-24T14:39:00.002-05:00

DHL Systems was located in the Bay area because it was felt that’s where the skilled systems people were. True enough, although the tech bubble had burst by now. Overall when I joined, DHL was owned by a combination of Deustche Post, Japan Airlines, and family of the original founders; then the Germans bought out JAL or something, and ended up as majority owners. (That’s why DHL vans and planes went from white with red/blue to yellow with black.) At some point someone in Deutschland decided that the Bay area was too expensive, so in December 2001, DHL Systems was ended. The operational part that ran the comm network moved to Arizona, but ATP was mostly dismantled and most of my friends end-dated. I think there was a lot of payback going on for past politics and disagreements. Somehow I, amongst a couple of other people, was offered a job elsewhere. Mine was in the London systems office I had visited. However, the salary was average, and not much was offered to help me and my family move. I also looked into what it would cost to put my sons in ‘american school’ in the UK, and that killed it. Probably for the best, as later on the London office was closed and the jobs moved to Prague. Nothing against Prague, never been there, hear its lovely, but I think it would have been too much of a culture shock.

…but, I am in the USA on an H1B sponsored by DHL. I start looking for a new job, but it’s a slim market, and no company wants to take over sponsoring me, so after some months its clear we have to move back to Canada if I was going to get work… so pack up and move, decide on Kitchener-Waterloo because we had been there before, my wife gets a job first, and then I get back into the workforce as a BA at a captive finance company, like GMAC, but it was for farm and construction equipment. So, out of the ivory tower and back into the trenches.

Afterword: I and my family certainly did like that time we spent in the Bay Area. Three out of 4 seasons was fine, although my son would go on school ski trips to Tahoe. We especially liked heading down to Monterrey and Carmel for weekends, and even just to Half-Moon Bay for the day, and drive up the coast to San Francisco. When I win the lottery, there is a little place on Monterrey Bay I may have to invest in...

Memories of IT - 2000's - Architecture and the Ivory Tower

2009-12-17T09:47:00.002-05:00

As the bringers of the new Architecture, we would get assigned to projects around DHL that say (or are told) that it will use the new way. The PMs would initially be happy, looking at us as another resource for their project. The shine would rub off when we recommended using the new methods to plan the project, especially if the PM had already built a plan. The other team members might get on board or, if the new way was very different from what they had been doing, they might resist. Eventually heated discussions would ensue, long conference calls, at odd hours depending where in the world the project team was.

The usual issue was the iterative aspect of the new architecture, which PMs or higher ups would be uncomfortable with because they wanted a completion date while we were looking to time-box the work and deliver what could be done in that time. Once during an all-hands IT meeting (DHL Systems and DHL USA), one of our key people raised a question about adoption of the architecture, and the senior guy in the room said iteration was never going to work in the real world. A sign of things to come…

The other angle in all this was that our Director actually reported to a VP in DHL central systems in London, U.K. This did mean that we would travel there and back on occasion. Having not been to the UK for decades, it was nice bonus, visited a few spots of interest; dropped over to Brussels once where DHL is actually headquartered, but all I saw was the airport, hotel and the office. The atmosphere in both locations was thoroughly byzantine, highly political, people jostling for position, you never knew when something you said might be turned around and used to bite you…didn’t happen to me but I saw it happen to others. The “Architecture” was often at the center of all this.

The thing was, though, the people I worked with in ATP are among the finest, smartest people I have ever known, so going to work was still great even with all the outside issues.

Quick aside: DHL was in the news a while back, and I know how it started. Back in 2000, DHL had no internal USA business to speak of; DHL was known rightly for being international. It also had a stupid way of measuring how it made money. Each country had its own DHL Corporation. Each one made money on shipments originating in its country, but got nothing for delivering shipments sent to their country, The USA got way more shipments sent to it than were sent out, so it always ‘lost money’, so whoever was running DHL USA looked bad. When I had this explained to me for the first time, I just could not believe it. I have to think that US management complained about this, but it wasn’t going to change.

So instead of more fairly reporting the real profits, DHL decided it would get into the domestic shipping business up against Fedex and UPS. They bought the smaller player Airborne Express, and then you started seeing yellow DHL trucks on the roads.

Well, seems to have not worked as DHL has announced it is getting out of US domestic shipping, going back to their focus on international shipping; hope they fixed their income reporting.

Memories of IT - 2001 - B2B and early days of Rosettanet

2009-12-15T21:40:00.000-05:00

After the Shipment Tracking project was over, I spent the next year working on several things, overlapping and simultaneously.

One cool thing was Rosettanet, the standards-based B2B architecture being developed, mainly driven first by IT and electronics companies. The idea was to define a set of supply-chain messages that companies could use with other companies who used the architecture. So, once you started using the message with one other company, you could then use them to communicate with other Rosettanet –using companies with little to no added effort.

One of the key set of messages had to do with making shipments of orders through a delivery company like DHL, including getting shipment status, and notice of delivery. So, Frank and I signed on as the representatives for DHL, and joined a working that included reps from Federal Express, UPS and a few smaller players.

The main deliverable consisted of XML message formats, with all the data defined that would need to pass from sender to receiver. ( A lot of the other messages sets were about automatically checking a suppliers inventory for desired product, then making the product order, and the supplier confirming the order, shipping --- which was our part ---, followed by invoicing. When we signed up, there were upwards of 100 individual messages defined, and about half had been created, and the first companies were starting to use them.)

Our messages were drafted during a couple days of meetings with all the reps, at a Fedex Ground location outside Pittsburgh. We took along an actual business person from DHL USA (also located near San Francisco) for Shipment knowledge. DHL’s acknowledged expertise at that time was in international shipments, so a lot of the message content about customs clearance came straight from us.

After that, we met weekly by conference call to iron out the final versions, after which they went through a formal Rosettanet review and approval process, after which they were published. The interesting thing about Rosettanet was the published services were free for any company to use, to spread their use, obviously. The core companies like IBM and others provided the most, and it cost to join in order to participate in development of the messages, worth the money if you made sure the messages were going to work for you.

I also went to one Rosettnet User Conference, in Chicago. A lot of it was about how to implement and start using Rosettanet at a company, with all day sessions or various tracks of one hour sessions, like most conferences. The basic structure was to have software sit in front of a company’s existing order and inventory systems, extract data as needed from them, use it to create the standard message and send them off. The same software would do the reverse as well, accepts messages, parse out the data and feed the existing systems. As you might expect, a number of vendors in the B2B space had already built and were hawking software packages to do just that, including services to automate the extracts from and feeds to existing systems. So, all the vendors were at the conference, of course. That always meant some free food and drinks and entertainment, which always helps make any conference more enjoyable.

In the end, the interesting thing was that some months later, Cisco and DHL entered into a logistics agreement, where DHL would warehouse Cisco parts around the world and deliver the parts when directed by Cisco…and their requirement was that these shipments would be triggered automatically using Rosettanet messages.

Anyway, its still out there, see www.rosettanet.org , check it out if you are serious about B2B...

Memories of IT - 2001 - Arguments over interfaces...solved.

2009-12-14T21:32:00.001-05:00

So, I deliver Use Cases and design/development begins. My group designs a service and interface following the Architecture. The KL systems people want a specific date/time-stamp form an existing system in the interface; our lead designer says no, that any other system using the interface should not know where the data provided came from, so that the service can be changed in the future without disrupting any systems using the service…. Things got quite heated. In a moment of prescience, upon hearing of this argument, I stepped in and said that this was a requirement issue, not a design issue. The date/time-stamp was actually the time a Shipment was first recorded in a DHL System. I added that date to our data model, then added it to the Use Cases, and the argument ended, at least publicly… there always seem to be some level of discord between DHL Systems ATP and Systems areas in DHL. We actually printed a poster of a white tower and put it on the wall heading into our office.

So, design and development went ahead for the pilot, was accepted, and then went live. For some period of time, at least, when you searched for your Shipment on DHL.com, you used a service based on my Use Cases.

Memories of IT - 2001 - Architectures, RUP, Iterative, BEA and other stuff in the life of Architecture Technology Pathfinding (ATP)

2009-12-11T15:23:00.001-05:00

This pilot was the first real test of the work of the group I had joined, known as Architecture Technology Pathfinding(ATP). The architecture in the title was actually multiple architectures, and multiple uses of the word.

The main Architecture was about application structure, and it was a detailed description of an N-Tier environment, with interfaces invoking Business Services which would then invoke Data Services and such. The implementation of it was based around the BEA web server product, and DHL Systems had in fact been an early customer and supporter.

But how do you define the applications? We were strong adherents to the Zachman Architecture Framework for starting with concepts, then models, then implementations of models down to code. Frank and I were focused on the Data Column of Zachman, with overlap into the Process column when defining the CRUD functions on data. In the application architecture these CRUD functions were the lowest level services that supported everything else. The overall approach across the architecture was service-based, with a service being defined and made available through an exposed interface, so that everything behind the interface was unaffected by what used it (and vice-versa) as long as it could provide what the interface said it needed. Very OO, of course, and a hint of SOA (which had not appeared as a term yet).

The other main use of ‘architecture’ was that as used in RUP, summarized as development of an application by first creating an overall architecture for the app, and then building it up in the multiple iteration approach of RUP (not Agile, which wasn’t a well-known term yet either). Selling RUP and its iterative approach was a big desire of the key people in ATP, as a means of moving away from a big-bang approach to development that had failed in the past.

The thing was, it had to be sold to IT execs in DHL proper, and there was one of those for almost every country in the world (although we focused on the USA and Europe as the likely place that success of RUP would then spread from.) Many an IT exec had blown off iterative, mainly because it was believed you could not define a specific end date for iterative development, and so you could not estimate it. The fact that past projects with planned target dates and estimates had usually missed both by wide margins didn’t count. The execs wanted something that made big-bang work, not something different they could not understand or felt they could control. However, the whole combined Architecture approach espoused by ATP had taken some time to develop, and had involved some other DHL areas, so it could not just be ignored. That is why the pilot for Shipment Tracking was devised, to illustrate the use of the Architecture and Methods. The complications came when the design started and some non-believers tried to undercut the whole thing….more next time.

Memories of IT - 2000 - ERDs, OO, UML, Use Cases and all that

2009-12-08T11:02:00.002-05:00

The first thing I did at DHL Systems was learn and use Rational Rose, and learn more about the RUP methodology. The aim was to figure out how to marry classic ERD data models with the Object-Oriented development modeling, especially the Class Diagram. This actually involved a lot of discussion with the OO experts in our group. I even went on another UML course (my first visit to Denver), but I still wasn’t grokking it. I also read one of those “UML for Business Modeling” books, but it didn’t help.

So, I translated some of the existing ERD models into Class Diagrams, and then tried my hand at some Activity Diagrams to model how some Classes would be created in a business transaction. Frank (my boss and fellow Analyst) and I showed these to our chief OO designer/developer, and his reaction was negative. His opinion was that UML is a software design language, not be used for analysis or requirements. He stated that what OO developers needed from Business Analysts was a “concept diagram” ( a generalized Class diagram that just showed what the main things of interest are) and Conceptual Use Cases. Frank was concerned that my hard work had gone for naught, but we moved on. Our Architecture group was going to participate in a company wide pilot to use UML, OO, RUP and a new architectural approach to create new services for tracking shipments through the DHL website. My job was to first write the Conceptual Use Cases, which would be used to create a design and concrete use cases, to be vetted by DHL IT in Brussels and built by another DHL Systems group in Kuala Lumpur.

There were no business people involved directly, the KL group was positioned as our ‘customers’. As such, any requirements they had were technical and cause for much wrangling between them and the OO folks in my group (more about that later). So, I went back to the big data models built in years past because, as you might expect, they were all about Shipments and all the supporting things you needed to pick-up, send, and deliver a Shipment. I created a set of Query Use Cases based on the data models that would accept enough data to identify a shipment (or at least a short list of candidates) and return whatever data you needed about the contents of the shipment, where it was and so on. I actually thought they were pretty lame, as my IEF days had installed in me the belief that queries and reports didn’t need requirements the way Create, Update and Delete transactions did; but, they were accepted pretty well, mainly because previous attempts had produced requirements that were either too vague, or too technical… I had found the middle ground. Then the real fun began as we moved into design…

Memories of IT - 2000 - A Canadian in California

2009-12-07T14:15:00.004-05:00

For any Americans reading this post, you should know... there are Canadians amongst you. And I don't just mean Jim Carrey or Mike Myers or Neil Young or (so I am told) one of the guys on "Glee". For a while, there was also me, my wife and my two younger sons.

A true story... my wife and I were shopping at a little outdoor mall in Castro Valley CA, and there were booths set up for the day selling crafts and such. One booth, however, was for voter registration. A nice lady in that booth asked my wife as she passed if she had registered, and my wife said she couldn't, to which the lady replied with "why not?". "I'm not not a citizen" my wife told her. The Lady asked "where are you from?", and my wife replied "Canada". The nice lady then exclaimed, "Really? You look just like us!" But then she took a beat and then said "well, that was a pretty stupid thing to say...". So, we never complain about Americans or the USA, we just offer useful information when we can.

It was a big move again, of course, but my wife had always felt she should have been born in California, and we would have been there long ago if not for the world's longest undefended border. For the record, DHL sponsored me on a TN Visa and then an H1B. I know H1Bs are a touchy topic for some, but DHL was able to show that they had been looking to fill the job for a while (and they had), and had been unsuccessful until they found me.I believe that's what visas should be used for, and that it helps the USA in that case. If visas can be abused in some ways, though, that's not good.

We settled in the East Bay, first in Castro Valley then later in San Ramon. That did mean I had to drive over the San Mateo bridge every day, and it had not been widened yet. However, commuting has been something I have always done, and in a lot less interesting places than San Francisco Bay.

It was a great place to live. If you live there, you already know that. If you have never lived there, don't worry about the earthquakes or the state going bankrupt or whatever, mover there if you ever have the chance.

On other thing before I get back to the IT stuff; we actually got to California by driving to Chicago, and then taking the California Zephyr train out to Oakland. We planned it as a mini-vacation (that also meant that my wife did not have to fly..), and it was a great trip, across the plains to Denver, then up and down both the Rockies and Sierra mountains. I keep hearing they might stop running the Zephyr, but if they haven't, I highly recommend it.

Memories of IT - Spring, 2000 - California, here I come

2009-12-03T21:36:00.002-05:00

Suffice it to say that I and my employer of three years parted ways in early 2000.

Through a series of timely connections and circumstances, I found myself on the phone with a fine gentleman from northern California, and that’s really when I first leaned about DHL.

Eight years ago, DHL was almost unknown in North America (and as it turns out, may be unknown again in a few years). The man who called me, his name was Frank, and he was soon to become and remains a good friend. Frank was the chief (and lone) data modeler in the architecture area of a subsidiary called DHL Systems, located in Burlingame, California. Burlingame is of those smaller cities/towns that hug the west side of San Francisco Bay between San Francisco and San Jose, just below the airport.

The group was similar to the TD group I had been in at Crown, and they were looking for a person with data modeling and information engineering experience to work for Frank. They had been having a hard time finding someone (really!), and apparently were willing to reach out far and wide in their search, and I had been found. After a good first phone conversation, they booked me a flight to San Francisco to be interviewed by Frank, his peer managers and the overall director. This was my first trip to the west coast and California, so it had the feel of an adventure. DHL Systems was in an office building right on the Bay, and I was put up at the suites hotel right next door.

Then off to a morning of interviews, lunch with the whole team at a fine restaurant also on the Bay, then back to meet with HR, during which Frank and the Director, Dee, came in and offered me the job right there and then. I was surprised, but I think I managed to respond professionally, said thanks and let me go home and talk it over with the wife and I will let you know… but it was pretty much a done deal right there and then.

Memories of IT - late 90's - More projects, and ETL tools

2009-12-02T21:36:00.004-05:00

!997, I am back in Southern Ontario, doing project work for my new insurance company employer, mostly forgettable stuff like how to restructure life insurance policies that had been sold on the promise of "Vanishing Premiums". I did escape the whole Y2K thing, so I can be thankful for that.

One interesting thing I worked on was ETL tools.I had done reading on Data Warehousing, especially Bill Inmon's seminal book on the topic. A lot of it was/is dependent on getting data from transaction systems into the DW in summarized, time-dependent structures. This was “Extract, Transform and Load”(ing) of data, ETL.

A different need for ETL came up at my new employer. Its growth had been fueled by acquiring smaller competitors. When you buy another insurance company, you get all its in-force (premium generating) polices, and all the computer systems that had been used at the company being bought. All of these systems were usually pretty unique, so my employer would end up having to run several systems for the same kind of insurance product, often variations of the same dominant insurance package system of the time. This was expensive and wasteful of resources, so the inherent desire was to migrate all the policies on all the acquired systems on to the latest/greatest system being used for new business.

That ain’t easy. Insurance is a non-physical product, so actuaries can dream up almost anything that they can sell and make money, and systems have to be customized to support very unique products. So the first hard thing to do was to figure out what the products/policies on the old systems really were, and if the new system could support them. That might mean the new system needs to be changed. After that, you have to get the data out of the old system, and get it into a format the new system could read and use to add policies. That could mean a lot of complicated and time-consuming programming, to create code that would only be used once, when the conversion from old to new system is done. My feeling was there had to be a better way, and a quick check of the marketplace showed that commercial ETL products were now available. I wanted something where the interface matched source data to the target database, accepted transformation rules, handled different types of files and databases, and generated the code to do the ETL process.

I found many such tools, and recommended we investigate them to acquire one to save time on ETL programming, as we had so many conversions to do and probably more coming in the future. I was in a line area, and most tech evals were done centrally, so I contacted the central area and they said they had no time, so go ahead yourself. So I contacted people in other line areas who agreed this might help them too, and got a part-time team together, generated requirements and went out and evaluated tools.

The best one was a product from an Austin company called ETI. It emerged from a research think-tank that major vendors and universities supported. It did exactly what I describe above.

I did up a full cost-benefit analysis, showed it was a good buy, and it had to go up to my VPs boss for approval because of all the other areas involved.

So we get the tool in, I and another analyst get trained, and we are lined up to do the next project, and then the push-back begins. The lead programmer decides she doesn’t want to get trained because she would have to travel, and she doesn’t like to travel, and the PM says OK. It becomes apparent that despite a good cost-benefit and management approval, programmers and some analysts don’t think much of the ETL tool; generating code meant no programming, and who wants that? They could not see that it meant no boring, repetitive programming, freeing up resources for new, interesting stuff.

So the whole thing stalled, which can happen when trying to implement change that frightens some people. It was too bad, the tool really worked as advertised. It was a sign...

Memories of IT - 1997 - Salary, Regina and time for moving on...

2009-12-01T20:43:00.001-05:00

One of the reasons for moving a company from Toronto to Regina is lower pay scales for your staff. If you moved from Toronto, you kept your current salary, but very quickly one raise or two would get you to the top of your job’s salary range and from then on your boss would say every year “I am really sorry, but no raise for you”.

Now, whether I really needed 2% raises or not, when this starts happening, you get annoyed. Also, some of what I used to do in TD about methodology was now thought to be needed again, and at a higher job level. I thought this sounded good and applied to the new position, All the people I worked with saw the job posting and said “Dave, that job is so you!” My application came back with a note that I was not right for the job. The HR person who told me this said that the senior IT VP hiring the position, who I had helped with methodology before, said he would be willing to meet with me if I wanted to discuss his decision, possibly a attempt to placate me as he was hiring somebody from outside the company he had worked with before. I most politely declined the offer, because I was steaming mad inside, and I may just have blown-up if I saw that VP. I shared this with someone I trusted and he said I had done the right thing.

This was also happening during my fourth winter in Regina, a horrible winter. So, all these factors came to a head and led me into an active search for a new job somewhere else. This was big decision, as I had worked at Crown Life for 17 years. It took a few months and I got an offer from a big insurance back in Ontario who would pay to move us back. I jumped at it.

Memories of IT - the 90's continue - the user from heck

2009-11-30T20:03:00.001-05:00

Next up was a desired enhancement and guess what, it was about Agent Management. In the United States, the rules for becoming an insurance agent are at a state level, so that means different rules in different states. Some of these rules had to with an Insurance Company sponsoring Agents, the proper way of registering, and if you did it incorrectly, large fines would result because the insurance boards took a dim view of people selling insurance who were not legally registered and sponsored to do so.

It’s a really complicated part of the business which (surprise, surprise) our vendor had not put in their system, but they sure would if we gave them requirements, and paid for the development work. Here we have another good thing this management had done, and that was assign the most knowledgeable business people to the project full-time to make sure the system did the right things. That is rare and to be applauded; unfortunately (!), management thought these people could write the requirements to send to the vendor, and that was a disaster. A document had been written, sent to the vendor and they sent it back saying it was unusable. So, a walk-through by selected team members was scheduled, and as an Analyst who had done Requirements before, I got invited.

The meeting was intended to change the document to make it usable, but it was just pages and pages of rambling text, so after some period of time I had to pipe up and say we needed to produce a real Requirements document, and I knew how to do it.

So, I am assigned an Agency SME and an Underwriter, the latter being the person who knew the rules, because underwriters checked these rules when a new agent submitted their first application.

The Agency guy was great; he was the one I had worked with before that liked my Data Models. However, the underwriter was the person who had written the original document, and was understandably not happy that her hard work had been rejected, and so she became my User From Hell. I scheduled a week in a meeting room to do the Requirements, but she fought me tooth and nail and it took four weeks. I did functional decomposition, a data model and rules, and she didn’t want to know that this could work. It was painful, and like all things you would rather forget, the specifics and severity of the pain have faded, but I do now that when we were done and the result was reviewed successfully internally and the vendor loved it, then that underwriter switched around to be the biggest supporter of what we had done… I felt good!

Memories of IT - Packages and Reverse Engineering

2009-11-29T13:13:00.000-05:00

Ah, packages. They are better now, but this was still a period where it was pretty likely you wanted to change it. One thing management had done right (and you gotta acknowledge that when you see it) was the vendor agreed to work with us to make changes if we gave them requirements. This was really one of those “win-win” deals, because almost all packages are created for the USA first and, if you are a Canadian company, the first thing you have to do is “Canadianize” the package; that can mean currency differences or adding French versions of screens and such. This vendor was indeed American, and we were their first Canadian customer, so they wanted to end up with a new version of their system to sell to other Canadian insurance companies.

They didn’t have such a version yet because the package was still pretty new. It had been developed in-house at a Chicago insurance company, and then it had been spun-out to a separate company. The original company was still their number one customer.

Was it a good package? I can’t really say for sure because (spoiler alert!) I wasn’t around to see it fully implemented. I do know the original version was not using industrial-strength technology. The database was some Dbase/Xbase thing, the code was Basic or something, and the user interface was green screen running under DOS; but the vendor wasn’t dumb. They piggy-backed on top of our agreement the effort to upgrade the technology: Oracle, Unix and other good stuff. This came about because the business liked the system as they saw it, but our IT people said we can’t support this, and our scale of business would probably swamp the system. So, the business people agreed to pay for the upgrade, and what vendor would not love that.

So, I have these D/Xbase table definitions, and there are hundreds of tables. The central tables emerged easily and I started subject areas, and the structure became clearer. What I found was that a lot of these tables were add-ons: if they had a Policy table, and then decided they needed more attributes for a Policy, they did not change the table, they created a new one with the same key. I can see how that would be easier to do, but it made the database into a dog’s breakfast. I raised this in one of the on-site meetings with the vendors, that I was not impressed, and they were not impressed that I was not impressed.

So, I continued parsing my way through this mess, creating a pretty big data model. I was doing this while starting to do direct project work, but I eventually finished. The next time some vendor people came in, I showed it to them as I thought it would assist in specifying good requirements and their impact on the database. Their response was muted at best, which left me puzzled. It was only some time later that I was taking to a consultant who had been part of the package search that I found out why I had got that response: right in our contract was a clause that we would not reverse-engineer any part of the system to understand and document it, that was verboten. Well, nobody had told me, I don’t think anybody else like who had joined after the contract was signed knew either. It was no secret I was doing it, and nobody ever said I should not do it. I don’t know if there were any repercussions from the vendor after they saw it, but I had the data model and I used it from then on.

Memories of IT - mid 90's - Activity Based Costing and Functional Decompositions

2009-11-27T12:16:00.001-05:00

Other stuff was happening in the 90’s, things like Business Process Re-Engineering, and Business Process Improvement. Crown Life got into a specific approach called Activity Based Costing (ABC), where you defined and broke down your overall process a few levels so that you figure what different parts did and what they cost. Each business unit had done this, and when I saw them, I said “great, these are Functional Decompositions.”

When I joined the Individual Insurance package project, I learned they had used their ABC decomposition to evaluate packages, and it was a good decomposition, functional not organizational. As I still had a licence for IEF, I put that decomp into IEF, as part of learning about the business before doing real work. What I found out, however, was that no data requirements had been defined, a big piece of the puzzle that was missing.

Turns out I had about a month after I joined the project before some real work started, so I said I would use the time to get up to speed. I said, do we have documentation on the package that I can read? Yes, we did, look in this LAN folder. In there I found table definitions for all the package's data, with foreign keys defined. I said to myself, I can reverse-engineer this stuff to build a data model to align with the func decomp, and I will have a great picture of the business, an actual Information Architecture.

So, that’s what I started, and started learning about the package too.

Memories of IT - mid-90's - Tossed out of the White Tower

2009-11-26T14:47:00.001-05:00

A little background on Technical Development (TD); it had existed in Toronto, and was staffed up again in Regina. We all worked for a middle manager, a couple of different ones who came and went. When one of them did move on, that’s when the VP I have mentioned previously took over. She had managed a large application area, and a re-org took away that area, and she came to manage us white-tower, R&D folks. It seemed like overkill to me, but it turned out that her job was to get the current of R&D projects done, This was mainly getting a server-based environment implemented that could be used to take over from the mainframe, which was supposed to be cheaper and better because it would be GUIs on PCs and such.

This reminds me that when we moved to Regina, our mainframe processing was switched from Datacrown/Crowntec to a local IBM/ISM facility, so we were still paying for every MF cycle and disc storage byte, so servers were seen as the solution.

So, at some point, it was divined that the server environment was ready, so we would never have to do R&D again, so TD was to be disbanded. It was like “the end of history…”. I also think it was because we were a senior bunch of people, higher-paid, and management decided it was time for us to work on actual projects and earn our pay.

So, we all dispersed across the company, and the VP got a new big app area to manage. I was concerned, because a lot of app areas were run by people who had declined to do IEM/IEF, and that’s what I was tagged with. However, I ended up joining the team doing the new Individual Insurance package, to do requirements for possible changes to the package.

So, back to the project trenches I went…

Memories of IT - mid 90's - The IAA from IBM

2009-11-25T11:47:00.001-05:00

What IBM had was something called the Insurance Application Architecture, the IAA. They assigned an IAA consultant to work with us, so he came in one day to do an overview. I was really curious how they could have a model that any Insurance company could use, as I had done some models and they certainly looked specific to my company to me.

So, he starts his presentation and gets into some detail and it dawned on me that this was an example of a concept that I had recently been learning about: the IAA was a “meta-model”, a general model that can be used for modeling something specific. In fact, it was a meta-meta-model, maybe more “meta’s” than that. So, about 20 minutes in to the presentation, it burst from my lips, “aahh, this is a meta-model…”. My VP and others in the room said “what?”, but the consultant said “Yes, you’re right.”

Apparently they had worked with about 20 client companies for many months in Brussels to come up with a data model and a functional decomposition. The decomposition looked reasonable, and had business words, but the data model entities and attributes seemed to have no insurance words. That’s because they had seriously generalized the “things of interest” such that a major part of the model would actually be used to define the business, with the rest used to actually capture data. I remember one subject area was Agreements, which would be used to define what your insurance products, but could also be used for any legal agreement. This was also the first time I saw what we now know as a Party model, a meta-model for defining customers and other business participants,

Because the model was general, it came with syntax for defining what data would be needed to do things like define a Product. It was at this point that my brain rebelled. I am a pretty Conceptual/Logical thinking kind-of-guy, but this was just too much. However, my co-worker who did tech support for IEF grokked it completely, so he and the consultant would sit in a room and spin out this syntax, and nod at each other and agree on stuff, and I would be in the room nodding like I knew what the f&%k was going on. I was worried, what if I never “got it”?

Skipping ahead a bit, IAA started being used for that Agent System. I had done data modeling with the business people about this just before IAA had been bought. The consultant and our IEF guy started holding meetings with these business people, and I joined the first meeting a few hours in, and the whiteboards and flip-charts were filled with the IAA syntax. One of the business people, a great guy, turned to me and said “I like your models better”. I felt a whole lot better.

In the long run, I need not have worried, as management totally blew the implementation of IAA. It was a general model, and very big, so its was recommended you start with a basic subject area like Party, and implement and start cutting your existing systems to start getting Customer data from the new Party system. It did not work well for doing a specific line of business or function, because you would have to use almost the whole model right away.

However, after evaluation and purchase of IAA, our VP sat down with the IAA consultant and said “OK, start with Agent Management and Compensation”. The rest of us meet with the consultant directly after this, and he holds us to secrecy to tell us that he recommended, even pleaded with the VP, not to do this, but she was adamant. So, that was that and those IAA modeling and syntax sessions began.

Now, doing this kind of modeling and analysis should likely have me involved, but I managed to avoid it somehow, it just seemed to default to the two other folks to do it. There were other projects going on, as usual, so they kept me occupied as well. I know that the IAA project did get to our tech guy writing some Action Diagrams and database generation in IEF to support party and agreement, but it stalled. I was still keeping up-to-date on the progress, as I still wanted to be able to learn and do this if it was going to stick around. What became apparent to me the doing analysis using a meta-model was next to impossible. If the model did not have business words like Customer or Policy, the business people would not get it and could never validate it. My recommendation was to do the analysis using logical models to capture the business requirement. It was true that systems built from such models would need to be changed whenever the business changed, and the power of the meta-model is that you make such change by changing data, not code. …But people can’t think ‘meta’’, so do the analysis logically, get it approved, then generalize it to the meta-model for use in subsequent development. My belief was that IBM should be able to build something that would take a logical model and generate the IAA syntax to use in the IAA model.

Unfortunately (again) for IAA and IEF, the overall desire to replace the whole CLASSIC system had reached fever pitch. One day, we heard from the VP of Individual Insurance that a package had been bought to replace CLASSIC and would also do Agent Management and such. So, that was the end of IAA.

Memories of IT - mid 90's - Life in a slightly white tower

2009-11-24T16:37:00.001-05:00

So I am ensconced in Regina, and IEF usage has plateaued, I am still in the R&D Technical Development area, and I start taking on various projects and research.

One of the projects was to pick a new Project Management tool. Crown has been using some older products but, as in other cases, a lot of the new people had been using MS Project, so the result was pretty much pre-ordained. I also looked at back-end tools for doing a PMO, merging of projects and resource management, all from partner companies. We did not buy any of those, but they would have been really useful on some future projects.

Client-Server, as I mentioned earlier, was getting big, and the merits of 2-tier versus n-tier was already coming up. Two-tier was quick and easy, but it was never clear where the business logic was run, so three to N-tier introduced intermediate platforms where logic parts of the app ran, between the screen and the database. I ended up writing a short methodology for client-server development (wish I had that one too).The thrust was to do your analysis and design so that it was produced in logical parts that could be implemented on different styles of CS, mainly 2 versus n tier.

Our group also did some internal consulting to project teams; mostly I would help do data models on projects. We were a group of about 8 people with different sets of expertise. Pretty much anything new in IT would be evaluated by us, sometimes with a project team doing a trial. I don’t think we ever repeated the evaluation disaster of CS tools.

And so the development cycle I have described before had come around to look at the Individual Insurance area of the company. It used a system called CLASSIC. CL stood for Crown life, don’t know what the rest meant. It was the first online app in the company, developed in the 1970’s in PLI and IMS. It got bigger and bigger over time. I recall that running a system test took forever, and cost a lot of money to run at Crowntek, so the VP in charge said you only got to run it once, and then you implemented. I never worked on the system; this was what I heard from people who did. The actual subject at hand was Agent Management and Compensation, which was sort of an add-on to CLASSIC and did not work well; At least two previous projects had tried to fix this and failed.

One day, our Tech Dev VP came back from a meeting with IBM, and announced we were going to buy a model from IBM for Insurance Systems that would help us with this and other problems. I know that there was also a latent desire to replace CLASSIC itself, which drove this choice. This was actually a second chance for IEF, as the model could be delivered in IEF, so that got me involved.

What IBM had was something called the Insurance Application Architecture, the IAA. ...more next time.

Memories of IT - mid-90's - Lessons learned about IT Standards in a Company

2009-11-23T11:58:00.001-05:00

So, I was now in Regina. Over the period of the IEF saga, I had moved from the Corporate Systems area to the Technical Development (R&D) area, which included methodology support (me!), hardware and software standards and new tech evaluations, and IT Training was in their too. This is where I watched some things happened and learned some useful lessons.

The first one was around those Client-Server tools I had mentioned before. There were a couple of leading tools that people wanted to look at and use, so TD was assigned the job of picking one…but some IT teams were clamoring to use a tool now to get something done (all those new managers wanting quick success). So, our manager and these managers decided that one team would try out one of the tools, and another team would try out the other tool, on real projects for 3 or 4 months… then they would all get together and decide which one had worked the best and that would be selected as our standard CS tool.

Can you see the problem here? Both teams learned to use the tool they had and built a system, and were happy. So when the decision time came, each team claimed that the tool they had used had to better than the other one, because they had delivered something with it. An underlying driver was that if one tool was chosen over the other, then the team that had used the ‘losing’ tool was going to have re-develop their system. Well, no one wants to do that, and any attempt to force a choice was denigrated as central TD not being flexible enough to meet the needs of each team.

Lessons learned:

1) Always have all reviewers of products being reviewed use ALL the products, so they can make a comparison; otherwise, they will prefer the tools they have used (if it is basically adequate for the task). There is big example of this: back when Wordperfect was still a viable competitor to Word, one group of Wordperfect users was asked to review it versus Word, and a group of Word users was asked to review it versus Wordperfect. The (predictable) result? Each group preferred the tool they had been using. You could have shown them an un-biased review that showed at a point time, one product was better than the other (until the next release of one of then came out), they would still prefer what they have used; that’s human nature.

2) IT Standards, that list of technologies and products that the company says it uses, is not useful for its specific content, but for measuring how much variance from the standard exists at a point in time… because there will be non-standard stuff being used when ever a standard is ‘set’, and powerful managers (that make the money for the company) will get exceptions from the standard if that’s what they want. Once you accept that, that the standards will never be absolute, you can use them to be able to advise people how much more money it will cost, or how much less support they will get, if they buy something that is non-standard. If that information is provided, you are helping those people understand the impact of their choice; they may still go non-standard, but with their eyes open and they can’t bitch later about lower support and such.

Memories of IT - 90's - why did we stop using IEF?

2009-11-20T11:16:00.001-05:00

Why did IEF development stop at Crown? It was the move; the majority of middle management and a lot of senior management did not move to Regina. As I have said, this gave the company a chance to downsize, so the number of staff after the move was 20 or 25% less than before the move…but that still meant a lot of people had to be hired. So, all the original stakeholders who had supported IEF were gone, and the new management had no stake in its continued use.

And IEF was really susceptible to this situation, because overall it was used in support of strategic redevelopment of all our systems, the original business case pictured this happening over the course of seven years, that’s a strategy.

But if you are a new manager in a new job in a new company, you don’t want to fall in line with a seven year strategy created by people who are now longer around, you want to deliver quick success, show that you are worth having around. That’s OK, and is acceptable in normal turn-over at a company; but with 60 to 70% of the managers all new at the same time, the IEM/IEF strategy (no matter how worthwhile) was dead.

I made a last stab at keeping it alive, writing a white-paper and doing presentations and such. I received great compliments on the white-paper -- I wish I had kept a copy --- but the response overall was “I can’t do that now”. I even presented how to use IEF on a more tactical level, just doing any project without an overall architecture. Jams Martin had figured out people wanted this and developed a one-project-only version of IEM called RAD (Rapid Application Development), and the promise of this version had helped sell IEM in the first place.

Unfortunately(!), this was the point in IT history when Client-Server development tools appeared, especially 2-tier tools that had you paint a screen, run it on a PC and it went directly against a database on a server. These tools did a whole lot less than IEF, but that also made them a whole lot cheaper, so when I would meet with a Project Manager about IEF, he or she would say SQLWindows was cheaper (and they had used it in their last job), so that’s what I am using, sorry.

And so ended the real saga of IEF at Crown. We kept our hands in it because of the Canada Pensions system, and I did get to go to some IEF user conferences. Such conferences are always in nice places, like Disneyworld or Vegas etc., so you take those perks when you can…but it was at one of those conferences, as described earlier, that TI announced it was selling IEF …and that was the real end.

Memories of IT - 1991 - Regina Bound...

2009-11-19T12:26:00.002-05:00

The company was in trouble, but who really knew that. I found over the years that I worked at Crown that my friends, family, and any one I met had never heard of the company. It did not advertise to the public, it marketed through agents and brokers. It also meant that though it was apparently the 18th largest insurance company in North America, I never saw much about it in the business newspapers.

Then, one day in 1991, the announcement came: a company from Saskatchewan (holding company for the richest family out there) had bought up control of Crown Life, and was going to move the company to Regina. That was news; it even came up in the Ontario Parliament question period, the opposition blaming the government for losing business/jobs from the province.

If you want to downsize your company staff, I can think of no better way to do it than pickup your company and move it 1000 miles, especially from the biggest city in the country to a relative hinterland. Current staff was offered the chance to move with the company, all expenses paid, or stay to a certain date and get a good-sized settlement. This was 1991, and Ontario was in a recession, so even if the settlement was good, opportunities for a new job were bleak. So, I decided to go to Regina. Looking ahead a bit, I can tell you that I and my family lived in Regina for 4 years. (A lot of people did not move, usually citing love of Toronto, wanting to stay near family, and many other good reasons)

I always tell people (truthfully) that I do not regret moving to Regina, but neither do I regret leaving Regina after those 4 years. I had grown up in Toronto and lived/worked in area of Toronto ever since. So, when I have been writing these posts, the place all this happened to me did not really affect what happened, it was in a big city, I commuted, lived in suburbs, like many millions of people. Regina was different, in both life and work, and that difference will come out in some of my future posts.

But it was over a year before I actually moved; a group of ‘pioneers’ went first to get started, using temporary space while a new head office was built and such. In the meantime, that Canada Pensions IEF project was still underway, had delivered some of the first parts of the system (structured by Business Areas), but it would not be done before the business unit made its move to Regina, and no one on the project team was going to move (they all felt skill in IEF was marketable, and I think that was true for a while). The unit management persuaded the team to keep working in Toronto after the move till the system was done, and they delivered a good system.

By that time, I was in Regina, about the only person with IEF exposure who made the move. One thing that I worked on first was a program by Texas Instruments for sponsoring education on IEF at universities, and we got the program set up for the University of Regina. I actually went out and spoke about IEF, systems development and Crown Life to a senior class. I didn’t think I made any impression, but apparently some students learned IEF.

I know this because the Canada Pensions IEF project did finish, and the Toronto team members all went on their way. So, the business unit had to get people in Regina to support and enhance the system, and usually new people need time to learn about a system before they can be productive; but, one thing the unit did was hire some UofR grads who had learned IEF, and because they could read the Data Model and Action Diagrams, they were productive almost immediately. It proved that systems generated from commonly known modeling techniques were a whole lot easier to maintain and enhance.

Unfortunately (and I feel I have to say that a lot), that Canada Pensions system was the first and last IEF system built at Crown Life…

Memories - early 90's - How not to do ISPs, and other stuff...

2009-11-18T10:30:00.001-05:00

The previous post mentioned one project I worked on, and it was probably one of several I may have been assigned to. If you work in a typical company, and you are not on a big development project, then you usually have more than one project on the go at any one time.

My focus was still around IEM/IEF. I would like to say it all went smoothly, but how likely is that... The company was divided up into about 12 business units at the time, basically a combination of product line and geography, like Canadian Life or U.S. Pensions. As a result, the IEM approach was to do an ISP for each unit, plus one for Corporate & Investments. I ran the ISP for Corporate as a trial of the process, and I and a James Martin consultant did manage to get the senior VP and his reports in a room for a day and do some models and prioritizations. That senior VP eventually became President, and he always remembered who I was whenever we met (it was not a huge company, so it was possible to see senior management around now and then).

Meanwhile, one business unit was chomping at the bit to go. It was Canada Pensions and it was the part of the business whose time for a new system had come. I can't recall if they looked for packages first, or if they really did an ISP, but they were soon off to do their data model, function decomp, got down to doing Action Diagrams. They had people go to IEF training, had a few experienced consultants come on.

Then the "while" I mentioned in my last post came to an end...

Memories of IT - meanwhile, back in the (insurance) business

2009-11-17T15:56:00.002-05:00

Ok, the last several posts have proved to be an arc on the one topic of IEM and IEF, like several linked episodes of a TV show. From start to finish, the arc covers several years, from the start of the project to pick IEM/IEF in 1989, to me changing jobs in 1997. A lot of other things happened, plus I have more on how we used IEF in the first years after we bought it.

A lot of it is better understood in context of the state of the company, which had been struggling. Crown Life was a typical Life and Health company, actually created by an Act of Parliament in 1901. Since them it had grown, entered and sometimes left foreign markets, added investment/pension products. Like a lot of companies in the 30 to 40 years after World War 2, it made money pretty much independently of any specific things management did or changed over the years; the basic business model was still working. So, Crown Life was a pleasant place to work, often referred to as the "Crown Life Country Club". Each president had come up from the Actuary ranks, and there were about 15 levels of management possible between worker and president.

However, the business environment for insurance soured in the 80's. I am not going to recount why, but stuff happens, and profits sank. Crown Life was a stock company with a few primary owners, and they eventually (mid-80's) sacked the last of the old-style presidents and brought in a turn-around guy, Bob Bandeen was his name. He had done the turn-around at CN so his arrival was momentous. After the usual few months of looking around, he started squashing those 15 levels to about five, so almost every day you would have seen some middle manager heading out the door with a box of stuff in his arms and a shocked look on their face. A noted financial writer of the time produced a book about the Canadian Insurance industry of the time, and it had a chapter for each of main companies; the chapter on Crown Life was called The Abattoir(!).

Amazingly, IT/MIS suffered very little, so in a strange way I was in a protected bubble of business as usual; I had to read that book to find out how bad it had been.

But eventually, Bob finished squashing and moved on. Crown Life sort of merged with Extendicare and created an overall company called Crownx (no typo); it was going to use Crowntek as a basis for getting further in IT services as a new business, selling PCs to companies, and other not-well-thought-out-stuff that sucked money from Crown Life and Extendicare until it was abandoned.

That left Crown Life in precarious shape. I had a bit of insight as one thing I worked on was cash flow reporting and investment management, which tried to predict how much actual cash was coming in from premiums and investments, and how much could be reinvested or kept for claims. What was apparent is that the flows were almost always mis-matched and the company was always short of actual cash. My absolute favourite moment was when we sold the head office building on Bloor Street in Toronto to some real estate company and leased it back, to get a cash injection into the company. I still shake my head over that one when I think of it.

I moved on to other stuff (like IEM/IEF) so my direct knowledge of company problems was reduced, and I suppose this and other tricks kept things going for a while, but not a long while. I will return to this topic when the "while period" ended in a future post.

Memories of IT - the death of IEF

2009-11-16T10:48:00.002-05:00

So, why isn't everyone using IEF today, and if you are of a certain age, why have you not even heard of IEF? CASE tools were a big thing for a while, which means many people liked them and many other people did not. The latter were usually put off by the rigor, they thought they were giving up flexibility. Programmers could be put off by the fear that it replaced what they did, whereas what it did was just move programming up to logical Action Diagrams, just like 3GLs had been a move up from assembler coding.

But two things happened that really killed IEF and CASE as a whole: IBM's AD-Cycle, and ERP systems like SAP.

AD-Cycle: As I said, CASE tools were a big thing in the years around 1990. IEF was only one of many tools you could buy, but the vast majority of the tools only did part of the job, As described in an earlier post, there were modeling tools that analysts would use but went no further; these were called Upper-CASE. Other tools existed that would generate code from some kind of input; these were called Lower-CASE. The Upper and Lower referred to the parts of the lifecycle the tools covered when viewed as a waterfall that went from high (initiate, analyze) to low (design, code, test). After a while, vendors of one kind of tool would partner with the vendor of the other kind of tool, and both would trumpet that you could now do the whole life-cycle if you used their tools together.

Unfortunately, there were so many tools that you could not just pick any two you liked; if you picked one, then only so many other tools would work with it. I suppose somebody though this was a huge problem or opportunity, because IBM (still the big player in the largely still mainframe world of the time) decided they had the solution.

You see, each upper-CASE tool had some kind of repository or encyclopedia to store its models, especially if you created them on a PC, after which you would upload to one repository that all modelers would have access to. Those repositories, like the tools, were proprietary to the vendor. IBM decided it would create one common repository that all tools could use, so you could then use any combination of upper and lower you wanted. Add some services and its own tools, and the whole thing is presented to the world as AD-Cycle. Immediately a whole lot of the most popular tools signed on to the program.

Remember, IEF wasn't upper or lower, it was the whole deal, which was known as Integrated-CASE. Texas Instruments looked at AD-Cycle and said, we like our own repository just fine and we don't interface to any other tools, so you folks carry on and when you have something usable we will consider it. (I am trying to remember if IEW did sign on to AD-Cycle, I think it did but don't recall why.)

The problem was that the AD-Cycle repository was a disaster. Real customers who bought it got something that was huge, slow and not very functional. News got around and sales tanked but, even worse, companies who had not used any CASE tools yet avoided all CASE tools, not just the AD-Cycle repository. The whole tools segment was hit, and this hit home to me when I was attending my second IEF user conference, and the main TI guy for IEF walked up to the microphone and announced that TI had sold IEF to a relatively unknown software tool company. TI was a hardware company, and they just decided a failing software segment was not for them anymore. The new vendor changed the name but eventually was bought up, and up and up, until IEF disappeared into the maw of Computer Associates. I changed companies not too much later (for other reasons), so that was the last I saw of IEF.

But it did carry on, and I think some version of it may still be being used by its original customers, but that was it.

What helped to finally bury it was the parallel arrival of the big ERP systems like SAP. They were selling to management that you could buy SAP and not have to develop anything. So, if you stopped in-house development pretty much cold, why would you buy an admittedly pricey I-CASE tool that was just for development? Well, you wouldn't, and that was that.

Memories of IT - IEF and Action Diagrams

2009-11-14T20:59:00.000-05:00

So, you have a data model detailed with all entities, relationships and attributes, and a set of elementary processes that mainly CRUD all that data. The specifics of those CRUD functions would then be detailed using a rigorous logic called Action Diagrams (AD) . You would define your input data, what the process would do with the data, and the output. The rigor of this logic was that all data used had to be in the data model, and the AD would use views of the data model to define input, output, and of course CRUDs of the data in the model. The AD also enforced the rules in the data model, such as the example in the previous post. If you did not specify it correctly, IEF gave you an error, The whole AD was supported in IEF as selection of logic phrases from only what was actually valid at the point you are defining the logic. This ensured that when you had finished the AD logic for a process, IEF could generate code free of execution errors. You could still define the wrong logic for the process, but it would run.

Last point: IEM/IEF defined a Process as a logical activity. When you wanted to use that process, you would create a Procedure, either an online procedure or a batch procedure, and these would use processes as needed, the key thing being that a process, defined once, would be used as many times as needed within all the procedures, like an online transaction for Add Customer, or a batch program that would get a file of data and use Add Customer as many times as was needed.

So, you have Procedures that use Processes that use the Data Model, all in IEF. The tool has assisted you in specifying all these things to avoid execution-errors, and it also had other validation capabilities that would ensure that all the pieces you have work together. Once all the pieces have been validated, select Code Gen and IEF created all the code for your application: DDL for creating the database, code for execution of process and procedure, and online transactions or job control language for the procedures. Send all that to the various compilers for the languages you have generated, and out comes your executable. No hand-coding needed; you can literally not look at and even throw away the generated code away.

IEF first generated COBOL, DB2 and CICS for mainframe systems. As client-server emerged in the early 90â€™s, they added generation of C, Oracle and Unix to run on PCs and servers.

Next time: So why aren't we all using IEF?

Memories of IT - early 90's - IEM and Business Area Analysis

2009-11-11T14:46:00.003-05:00

So, you have enough of a business model in IEF to divide the enterprise into cohesive Business Areas (BAs), which now need to be detailed enough to be a complete requirement for systems. The planning mentioned previously will indicate which Business Area to do first. Other than the limits imposed by natural build sequence (data created in one BA needs to be built before other BA'™s can use it), you could do the work on some BA'™s in parallel if they are not directly dependent. In IEM, this step was called Business Area Analysis (BAA). This was done by mainly parallel decomposition of the high-level data and function models.

Most people would not think of a Data Model as hierarchical, as it usually happens in reverse. You start putting Entity Types on a page, connecting them up with Relationship lines, and soon you have a lot of boxes and the page is filling up. Design studies tell us that the optimum number of objects to draw on a page is seven plus or minus two, or the human brain doesn't comprehend it well. Less than 5 is usually not a problem if not that useful, but more than 9 is.

What you will see is some entity types have many others hanging off them, often called central entity types, like Customer, Product, Employee. Each of these is the central entity type of a "Subject Area", usually named as the plural of the central entity, so Subject Areas are Customers, Products, Employees. Group all your entity types this way and you have a 2 level hierarchy of data. IEF supported this grouping into Subject Areas, and then further groupings of Subject Areas into a higher Subject Area, so a multilevel hierarchy results.

Meanwhile, you have a level or 2 of functions, more formally known as a Functional Decomposition.

Decomposing an enterprise is analysis in its purest form; understanding a thing by examining its pieces and how they relate to each other. You look at a thing/function and determine what are the seven plus or minus two sub-things that comprise the thing.

IEM defined a functional decomposition as composed of two types of "things", Functions and Processes. A Function is an activity that is continuous, no obvious start and end, like Marketing. A Process, then, is an activity with defined start and end, like Create New Marketing Program. So, the decomposition will start with some levels of functions, then each path of decomposition will reach a point where the next level down is a group of Processes, and then remaining levels of that path will be processes.

Functional decomposition usually gets criticized or can get misused. The most common misuse is that people think that functional decomp is the same as the Org Chart; it is not. The best way to realize this is think about how many reorganizations you have been through ---probably lots---, and how many times this actually changed the work you did --- almost none ---.

If determining the decomposition is difficult, some advanced IEM methods recommended parallel decomposition, meaning in parallel with the data model, so the function Marketing is parallel with the subject area Markets. Given this match, you decompose both models together. When you get to Processes, they will be verb-noun, where the noun is an entity or attribute in the data model.

All this decomposition is done to get to Elementary Processes, which answers the question "how do I know when to stop decomposing?". Each process will define how data in the data model is managed. A good process is one that manages data and leaves the data model in a valid state. So, if a process creates an occurrence of an entity and it has a mandatory relationship to another entity, then the process has to create that one too, otherwise the state of the data is invalid. A process that creates only the first entity is sub-elementary, and you have decomposed too far.

IEF supported this functional decomposition, enforced some rules like Functions can be composed of Functions or Processes, but Processes only decompose into other Processes; and it had you indicate what you believed to be the Elementary Process. The interesting thing is that all of this decomposition is done to get to those Elementary Processes; once they are all defined, you don't need the decomp any more.

(Note; this definition of process is not the same as that for Business Process Modeling or Re-Engineering.)

Next Time...Action Diagrams

Memories of IT -into the 90's- What was IEF,anyway?

2009-11-02T22:03:00.002-05:00

The decade turns...

What was IEF, anyway?

It was automated Information Engineering. That methodology was based on information across a whole enterprise, so its first step was to create the Information Strategy Plan (ISP) for a complete enterprise. The core task was to create a high-level model of the enterprises functions and data (remember, function + data = information). This was indeed high-level where the data defined was Customers, Product, Materials, Staff, and such. The functions were the first to second levels of a functional decomposition, usually based on the main activities of the business: Define and Market Product, Acquire Material, Make Product, Sell Product, and supporting functions like Hire Staff and Create Financial Statements.

The functions were always defined as doing something with data. Given this perspective, you could create the CRUD matrix, Data items on one axis and Functions on the other, and each matrix cell contains the letter for Create, Read, Update, Updateâ€¦or blank. Given this matrix, you can now do Affinity Analysis, which is a process of identifying what groups of functions manage a Data Item. I did this manually back in an earlier project.

But IEF captured the Data Model and the Function Model, and the CRUD matrix; then you initiated an automated affinity analysis process, and out came your restructured matrix. The result is a set of clusters of functions managing a set of data, which are de-coupled from each other. Each cluster was then used as the definition of a Business Area; a typical enterprise would have 5 to 9 Business Areas defined.

This is your Information Architecture. The IE Methodology (IEM) then provided a series of evaluation and analysis tasks to determine how well current systems support each Business Area, what is the value of automating a Business Area, and suchâ€¦from which you would create a plan, the Information Strategy Plan, for moving from current systems to a new set of Business Area-focused systems that would eliminate silos, data duplication, etc..

So, now you were ready for Business Area Analysis...

Memories of not IT

2009-10-30T15:26:00.002-04:00

It has been pointed out to me by one of my offspring that he and his brothers have not been mentioned in these posts. He found them because they are being replicated over on Facebook as Notes, and he thinks by reading them he might understand what I have been doing for 30 years that put a roof over our heads and food on the table.

Unless requested, I will leave names out of this. I did marry my lovely wife in 1979, and sons arrived in 1981, 1986, and 1989. My wife claims she remembers nothing about the 80's except diapers and formula (I did my part too, so sleep-deprivation was equally shared).

It might be useful for these posts to give some geographical context, because it does start changing later on. I grew up in what was then the suburbs of Toronto, a place called Etobicoke (KE are silent). I went to University of Toronto (which I think I mentioned). My employer through the 80's was located in the "middle" of Toronto, Yonge and Bloor. When I started, I could take the bus and subway to get there, then we moved further out, so a car to the subway was needed, then we moved much farther out in order to afford a house in the time of 15% mortage rates, so that meant driving/carpooling , or commuter (GO) train and subway. The drive took an hour when we first bought our house, it was up to two hours ten years later.

Overall, the sons came along in a fairly stable time in terms of where we lived and where I worked. The company had a Children's Christmas Party each year, right in the head office, so children could be taken up the elevator to see daddy's desk. It's state of organization must have made an impression, because I started getting presents like mouse pads with the Tasmanian Devil on it whirling around leaving destruction in his path.

But things would change and become quite interesting, as you will see in future posts...

Memories of IT - 1990 - IEW vs. IEF

2009-10-28T22:55:00.002-04:00

1990, and the promise of CASE was huge...

We have two products, IEW and IEF, to choose between.

Memory and perception can be funny things, so when it comes to IEW (Information Engineering Workbench), any corrections from the reading public are especially welcome.

First off, I recall the vendor company'™s name was Knowledgeware. Its president or CEO was one Fran Tarkenton, indeed the famous NFL quarterback. I never did figure out what he really was to the company: was he a closet geek who really was involved in the product? Was this where he invested his NFL salary? Was he a figurehead? Comments welcome!

The other angle was that Knowledgeware was supposed to be very closely related to James Martin, but in what way I can't be sure. The implication was that if you were really doing Information Engineering, then Knowledgeware and IEW just had to be your choice.

So it surprised me no end that when I saw the product demonstrated, its functional modeling was based squarely on Data Flow Diagrams (DFDs). It might seem like an esoteric issue now, but if you had followed the methodology advancements of the 1980's, you would have seen that DFDs had featured strongly in Structured Analysis and Design, but they had fallen into disfavor with the rise of Information or Data-centric approaches using Data Modeling. In these approaches, DFDs with data flowing around and many Files were thought to lead to bad data design, silos and all that. And IEM (The methodology) did not use DFDs for functional modeling, it used a straight Functional Decomposition; but, you could probably have used DFDs without breaking any methodology rules.

On the other hand, there is IEF (Information Engineering Facility) from the software division of Texas Instruments. TI is really an engineering, hardware company, but they backed into selling a CASE tool because they had bought into Information Engineering for their own information systems and wanted a tool to support it, so they built one. IEF was automated IEM, for sure, but with a focus on the parts of the methodology that led to producing code; any diagrams that didn't lead to code were not automated. One of these was, in fact, DFDs, which IEM did use in a limited way for documenting current systems, but no more, so TI kept them out of IEF.

In the end, it came down to code generation; both tools generated code, but IEF was the most complete and straightforward; IEM was missing some parts and impressed ourt technical people less. So, IEF emerged the winner.

Next time: What was IEF, anyway?

Memories of IT - 1989 - Methodologies and CASE tools

2009-10-27T20:50:00.002-04:00

1989...

As per my previous post, we have a couple of methodologies to evaluate. PRIDE was all about Information Resource Management; IEM was, well, about Information Engineering. If I was to line them up against each other today, I am not sure there would be much difference between the two, except we knew that IEM had two popular CASE tools supporting it, so PRIDE never really stood a chance.

So, IEM won. This was James Martin's baby, through his latest organization, James Martin & Associates. At the time, they had a Canadian office that we worked with, so I don't how many degrees of separation there was between myself and James, but it wasn't close. He was doing tours at that point, charging large sums; when he did come through Toronto, only VPs of my company got to go. I recall he was already moving on to new topics, like Enterprise Engineering and Value Flows...

Meanwhile, back on the project, we have IEM, so now we look at supporting CASE tools... but let's talk about CASE first. Computer Assisted Software/System Engineering. There were actually a few different angles to it. It had started with the model/diagramming tools I have mentioned before. Because they supported tasks in the first few phases of the SDLC, they were tagged as Upper-Case, meaning the diagrams were good but it stopped there. At some point, other vendors created code generator products which, because coding happens later in the SDLC, were tagged as Lower-Case; then vendors of both types of tools would hook-up, so that Upper-Case diagrams could be used (somehow) as input to the Lower-Case tools to tell them what code to generate.

I never saw a Lower-Case tool up-close, so I never knew how they worked independently, or how interfaces with Upper-Case tools really worked. I never did have to know that, because we were looking at the third angle: Integrated CASE tools (I-CASE, long before i-pods or other such stuff). This was a product that did the whole SDLC, from first diagrams to final code gen and testing, and there were two main players: the Information Engineering Workbench (IEW), and the Information Engineering Facility (IEF).

Next time, comparing IEW and IEF...

Memories of IT (late 80's) - new Methodologies... and tools?

2009-10-21T23:10:00.002-04:00

It's always amazing how much you don't know, or even worse, what you don't know you don't know. A new analyst joined us for the new methodology project, and we were discussing various tools for modeling and analysis, and he informed me, to my initial disbelief, that there were tools out there that could generate complete systems from Data and Function models. I thought I was pretty good at keeping up with trends, but this had escaped me, so it was time to catch up.

This happened within the context of our new development methodology project, which also included CASE tools that might support such new methodologies. The approach was pretty good: find the methodology that best met our needs, and then pick a tool that best supported that methodology. I was the lead analyst, charged with gathering requirements that would be used for RFPs and detailed evaluation. Key IT people from each unit participated in requirements sessions. I know we produced a good, long list, but the details have faded from memory. This group was not working in "controlled isolation", so I am sure that what any or all of us knew about existing products, and also from looking ahead to tools, influenced the results. I know I was already looking for candidate products, and reading up on all of them.

What emerged from the requirements list was a desire for a methodology that helped us deliver low-maintenance systems, and wouldn't it be nice if a tool automated that methodology to speed up the process a little. Of about a dozen methodologies I found (pre-Web, so the big magazines like Computerworld were a key source), there were only a few that matched up in any real way. One was PRIDE, which is still out there, and the other was the Information Engineering Methodology (IEM) .

Next time, looking at the two methodologies...

Memories of IT - circa 1988 - The Maintenance Dilemma

2009-10-13T22:07:00.002-04:00

My company's management, IT and Business, were now grappling with the 'maintenance problem', the generally agreed dictum that 75% or more of a company's IT 'development' budget was actually spent on fixing and enhancing its existing systems, leaving little for delivering the new systems everyone wants to support new business initiatives.

The standard reaction was (and is) usually to find some way to get more new development out of the available resources, resulting in the adoption and eventual abandonment of many tarnished 'silver bullets'. A less common but no more successful approach was to find ways to maintain those existing systems with fewer resources: code analyzers, reverse-engineering in models, and such.

The third and least used (and least understood) approach was to recognize that systems had to be built from the start to require less maintenance effort, so that the 75-25 resource split could be moved towards 50-50 or better. This requires a long-term strategic view of your information systems inventory, one that recognizes that over 7 to 10 years, many of your current systems will be replaced, so why not do this following a strategic plan; otherwise, you will end up in the same state in 10 years, with a few new systems.

One thing that anyone reading this will agree on is that thinking out 7 to 10 years is difficult for the average company, even for its core business of what it sells or services; taking such a long term view of its supporting information systems is really difficult. The allure of the quick fix can be hard to resist. So, in retrospect, the fact that the average insurance company I worked for would even consider a strategic approach to its information systems still stands out as an amazing development that would take my own career down a new path... to Information Engineering.

Memories of IT - when I started to learn about Methodology

2009-10-08T19:49:00.004-04:00

So, these posts are still in the 80's, but a lot was going on. By coincidence, both I and my company were thinking more about methodologies and the system development life cycle. Looking back, it's hard to explain that we weren't really thinking in these terms, work just got done, a simpler time I suppose. Of course, the idea of using a methodology was not new in the mid-80's but it wasn't accepted everywhere either.

The only real methodology concept I was exposed to early in my career was the Scheduled Maintenance Release. Working on an existing system, requests for change would come in at any time. I suppose at one point before my time such changes might be dealt with as they arrived, but it had become apparent that this was not a best use of resources. It became clear that "opening up a system" for changes carried a certain level of cost irrespective of what the change was, including implementing changes into production.

So, change requests were evaluated as they came in (production bugs were fixed as they happened); if the change could wait, they went on the change list. At a future point, either on a regular basis or when resources were available, all the current changes were considered for a maintenance release project.

As I worked in a department where the systems were relatively small, and project teams may be one person, I don't recall doing much estimating or cost-benefit analysis for these projects during that era. Releases might be organized around major functions, like all changes for month-end reporting. Once a scope and a set of changes were agreed to with my main business contact, I just went ahead and did the work. I remember that I would figure what code changes were needed, do them, and test them. For the small systems I worked on, I don't recall there being separate unit, integration or User Acceptance Testing.

If you have read my earlier posts, you will know that I did work on a large in-house development project as a programmer, but I can't say if the project was following a methodology. I came on the project during construction, and all I remember was that the PM/BA did write and give out what would be considered Specs today. I think she also did the integration testing of the system as we delivered unit-tested bits.

But there was indeed some work on Methodology work going on in the company... One day some of us were scheduled to attend training on the company's new System Development Methodology (SDM). Apparently one or two people in IS Training had been developing an SDM (still had that in-house bias). So off we went; to the creators' credit, I recall it what we saw was pretty good. This is probably when I first heard the word "phases", and that there were at least 4 or 5 of them in this SDM. Unfortunately, creating an SDM is a lot of work, and so far they had only completed the Analysis phase in detail, the rest was just the framework. They said the remaining phases would come over time; well, time ran out on this work when someone figured out you could buy a whole/complete SDM, so the remaining phases were never done and the in-house SDM was never mentioned again.

... but I recall it was my IS department that then went out and got an SDM. The winner was from a local consulting company, who offered "The One Page Methodology"; methodologies were already getting the reputation that they were big and unwieldy, and the manuals would be put on a shelf and never used again. Now, this "one page" was as 4' by 2' foot wall-poster, but it served the purpose. The poster was divided in to 5 horizontal bars, one for each phase, and each phase had around 10 boxes/steps, going from left to right, but that's all I remember.

What I do remember was the vendor also had a CASE tool, called "The Developer", to automate the diagrams used in the methodology. These were basically data models and data flow diagrams. It also had a data dictionary for the data model, and text boxes for documenting your DFDs. So, Excelerator was gone, replaced by this Developer.

I used it quite a lot as I started doing analysis on a lot of smaller projects. I can't say that our developers got what the models were for, but it was mostly current system maintenance so they would ask questions and figure it somehow.Not sure how this situation was tolerated, but things were changing all the time, so newer methods and tools were coming...

Memories of IT - mid-80's - Analysis and CASE Tools

2009-10-07T22:55:00.002-04:00

So now I move on to the next project, replacing yet another batch system with something newer and shinier, and I am doing the Analysis phase. In a timely fashion, a few things arrive that will help me greatly...

a fast, collating, stapling photocopier, which I would need for distributing the requirements documents
an IBM PC AT, with a hard drive, a mouse, and a graphics card. The drive storage was tiny by today's standards, 10 meg. The monitor was still monochrome, an annoying orange-yellow.
and the reason for the AT, a copy of Excelerator 1.0

Excelerator was my first CASE tool. I think the vendor sales guy drove up from Boston to Toronto and gave us a copy out of his trunk. I entered my level 0 DFDs in it, and then I could easily change it as needed. When it was stable, I would generate a print file on to a diskette, and then go to a PC attached to a plotter to print the diagram. (No LAN yet.)

Next, I could select a level 0 function, and then draw a new diagram , exploding that function to level 1, keeping a link to level 0. This was like gold for me, so pencil and erasers were now history.

Excelerator did not support Data Models in 1.0, but I used a general diagram to at least draw the diagram and kept definitions and such in a text document.

Looking back, I would have to say that the quality of what I produced was probably low, but I was young, all was new, and there weren't many examples to compare to. I am fortunate to have had the time to learn and improve since then, and it hasn't stopped; there is always room for improvement, and new things to learn.

Memories of IT - still in the 80's - They didn't call it downsizing yet...

2009-09-29T21:18:00.002-04:00

Ok, now I am trained up to be a Business Analyst, and an opportunity to be one was about to present itself. But first, a little about changing environments.

When I joined and for the first few years I was there, Crown was PL/1-IMS mainframe shop with all systems developed in-house. I don't know how this came about, as so many companies used COBOL and VSAM files. The fact that Crown Life did not use COBOL was one of the reasons I accepted their job offer in 1979. The only old war story I heard from some company veterans was when the first computer was installed at the company in the mid-60's. It was a big deal, all about "turning the big switch" to move the company on to using a computer.

Development of new systems moved in cycles, of course, depending on what needed built/replaced, allocation of budgets, etc. After the development of the new Stocks/Bonds Admin system was done, the focus moved to the Group Insurance business. Crown Life did a lot of business in the United States, like most Canadian insurance companies of any real size, and it was still possible to make money in group health business as well as life, before health costs sky-rocketed and HMOs took over.

So, the company had a number of group sales offices around the United States doing business, and they needed a new system. Something about the cost of using billable mainframe cycles probably played a role in the decisions to create a system based on a mini-computer located in each sales office, which employees would use all day, and each mini would then feed the days transactions to a master system on the mainframe in Toronto for consolidated processing; sounded reasonable, I guess. Adding minis to our mainframe environment was new, and probably should have been treated as a risk, but I was 26 years old and not on that project, so can't say I worried about it much myself.

The team for this project was located next to the department I was in. I recall that I did not know many of these people directly, but they seemed like a good enough bunch. Reporting about project status to people outside the project always presented things in a good light, but that kind of reporting usually does, no matter what is actually happening.

Because something bad was happening on that project; I found out about it like most of the rest of the company when I came to work one day and the area with that project team was empty, and stayed empty. The mini-mainframe mix had not worked out (more on that later), so the project was cancelled and the whole team up to director level was let go, fired. I don't believe the 'down-sizing' euphemism had been invented yet, but this was the first one I ever saw like this, quick and brutal. I think this was the cause of me realizing what a lot of other people were realizing as the 80's progressed: companies could just not afford to be completely loyal to their employees, so it was time to start managing your career yourself, start looking out for #1. Obviously this is when employee loyalty to their employers started to disappear too, and management magazines over the next 10 years or so had to gall to print articles asking "why?".

Anyway, the Group Business division still needed a system, so senior management brought in a new team that went right out and bought a Group Insurance COTS package. It was totally mainframe, so whoever wanted to avoid mainframe costs was ignored (or had been one of those who was fired), and it was COBOL-CICS-VSAM.

This was the first package I had seen purchased at Crown Life, so the developing of all systems in-house could not be assumed anymore; and the pure PL/1-IMS environment was no more. Business realities would now drive what systems and technologies would be used.

PS: About the reason why the mini-mainframe mix failed... about 5 years later, I was on a training course near Washington DC, and the direct flight for myself and a co-worker also attending back to Toronto was canceled. So, we ended up on a travel nightmare, taking a flight that stopped 3 times and we had to change planes once. A couple of other travelers were doing the same thing, so we got to talking (especially in the bar between planes) and turned out they were AT&T techies. When I said we were from Crown Life, they rolled their eyes and said that we may not want to hang out for the rest of the trip.

Why? It turns out that for the minis in those Group offices to communicate each night with the mainframe, they would need special or dedicated lines (any network techies reading this will probably know why). In those days, those lines were not easy to get, and Crown Life ended up on a waiting list measured in years. When that situation became apparent to all, it wasn't too long after that I came into work and found that project team gone.

PPS: Crown Life apparently sued AT&T over this. They had a contract, of course, and they claimed the delays breached the contract or something like that. As a Crown Life employee, I never heard about this lawsuit, but the AT&T guys we were traveling with sure had; I don't know how the suit ended up, but Crown Life was not a favorite of AT&T for a long time; but us foot soldiers who had met at random decided we would have a few more beers and not let company issues bother; we just wanted to get home that night.

So, when I started on the next big project, all assumptions had changed.

Memories of IT - 1984 - Structured Techniques

2009-09-28T14:05:00.002-04:00

So, this many posts in and I am still less than 5 years into my career... but an important shift in the story is imminent.

As I came off pure programming work like the new devevelopment project I have been describing, the Analyst part of my Programmer/Analyst job title started to dominate. Some of it was the work I moved on to, but also a parallel path of training that the company paid to have me attend. Everyone has a complaint or two about anywhere they have worked, but my first employer did understand that training was vital to the development and overall happiness of their employees.

Some of the training was general skills, like public speaking and on giving presentations. On the IT side of things, structured techniques were all the rage, broken into the parts of Structured Analysis and Structured Design. As I was still primarily a programmer, I recall I attended a Structured Design course first; it was given by an external vendor. The actual diagrams and techniques have faded from memory, but I do recall it is where I first learned about"high cohesion" and "low coupling". The course also showed how it used the results of Structured Analysis as input to Structured Design.

So, I continued along, doing enhancement work on existing systems. Understanding what the business wanted out of the enhancement, and then determining the impact it would have a on a system was the majority of the work; the actual programming work needed could often be minimal. So, it seemed like maybe I was turning into an Analyst who programs a little. I think the company did have the Business Analyst job title already, so I veered my career path towards that title.

That meant I got to attend the next offering of Structured Analysis training. The course used one of the era's gurus as a basis for the course: DeMarco or Constantine or Yourdon or whomever. I should have kept my course material, it would be a classic now!

It was on this training I was first introduced to the Data Flow Diagram, orDFD. The idea of diagramming what your system should do really appealed to me, even if the diagrams were hand-drawn and hard to change. Pencils and erasers is what I remember of the course and subsequent work back at the office. That would have caused a lot of people to use it less or stop using it, but not me. My future was being defined right there in that course.

Next time - the next big project

Memories of IT - unexpected consequences of system development

2009-09-16T15:11:00.002-04:00

(Actually, I need to wrap up a few things and start a few others before I get back to PCs...)

So, I came off of the big PL/1-IMS development project, as it wound down, 1983 or so. The system from my viewpoint was brilliant, supporting all the stock and bond investment business of the company. I worked a lot on look-up screens, starting with a definition of a security and breaking it down to all the lowest levels of investments the company had in that security. A friend of mine was quite proud of a program he wrote to allocate bond income across the company's complete portfolio after one hit of the enter key. However, it still faced two challenges:

1. the easy-to-program architecture of the online system did require more of the system to be loaded in memory at a time than an architecture based on a single screen structure. As a result, the online system always had lowest priority among all the online IMS systems, and so response to the users was always slow.

2. the actual securities traders had been doing business over the phone and writing down their trades on scrips/paper, then handing these to clerks to code up transactions to feed the existing batch systems. A major proposed benefit of going to an on-line system is that the traders would now enter their trades directly into the system, giving real-time updates and removing the clerical effort. So, our BA/PM shows a test version of the system to management and the traders, to show just how this was all going to work for them. Apparently the traders weren't aware of this benefit, and they reacted very negatively. Typing anything was for clerks and secretaries, so using a system that required typing was beneath them. So, when the system went live, traders continued to write their trades down and handed them to the clerks, whose jobs continued but as the new users of the online system.

The system did go on to have a useful life of about 10 years. I did not work on it again, so I don't know if the traders ever warmed to it. I do recall some outside consultants doing reviews of our existing systems later in the decade, and they said something stupid about this one; given its volumes compared to say, our core individual insurance systems, they wanted to know why we had not developed it on a mini-computer. I think the architect,s head probably almost exploded. I suppose not owning a mini-computer did not mean anything, nor the fact that that the company's core IT skills at the time of development were all on mainframes. By the time of this review, however, other changes had occurred; packages were being purchased, which meant COBOL and CICS were invading our previously pristine PL/1-IMS world. The architect left the company not too much later. Breck Carter, wherever you are, if you see this, drop me a line.

Memories of IT - PC enters the home, then the office

2009-09-14T13:07:00.002-04:00

In the early 80's, I was one of the younger people in my department, even with regular new hires coming on. It would actually annoy some people...

However, we would also have co-op students, who went to university for a term, then work at a company like ours for a length of term, then go back to school. The good ones would be invited back for more work terms and often came on permanent after graduating. It was at a work-party hosted by one of these students that I saw my first personal computer. I think it had to be an early Apple, but can't be sure now. Anyway, the main thing it was running and people were trying out was one of those Alien Invasion games: bad aliens dropped from the top of the screen and you moved your weapon left and right on the bottom of the screen shooting upwards to kill the aliens before any got to the ground. Well, I thought this looks like fun, and took my turn to play, but as my previous post said, eye-hand coordination is not my strong point, and you had to use certain keys to move and shoot which I wasn't familiar with, so I lasted about 30 seconds before I lost. The surrounding young folks hooted and basically told me I sucked, so I left the game room, returned to the rest of the party and got a beer. If that was personal computing, I said to myself, then they can keep/stuff it. When the young folks weren't playing the game, they were going on about programming the thing, in Basic I guess, which I thought was mickey mouse; I mean, I programmed an IBM mainframe for a living, you could stuff your toy programming too.

So, all in all, the arrival of the PC was not something I was promoting any time soon; but one day, an IBM PC was delivered and set-up in our department. character-based screen and two floppy drives (A: and B:), and a daisy-wheel printer attached. I have to think that the amount of mainframe cycles and laser printing we were using for documents was seen to be costing too much money, so what about this PC thing for doing that?

First off, many people thought the printer was horrible, still using fold-attached paper fed through a wheel with a print quality barely above that of crayons, so people stuck to their PDS members and mainframe laser printing. The thing that got one person using the PC was Visicalc, the first PC spreadsheet. It was the BA/Manager of the big development project we were all on, and she had to do either a business case or status report with a lot of numbers to calculate and add up; well, she thought Visicalc was even better than sliced bread, and I can see why. There was nothing like it in all our mainframe programs and utilities; she might have been the first person to eventually get her own dedicated PC.

Meanwhile, the rest of us are trying out the PC as encouraged by our managers, so you sit down with at least three 5.5 inch diskettes. The first is DOS; insert it in drive A and turn the PC on. The machine would boot, and I don't recall it taking too long (long boots were still in the future). Once you get the A: prompt, take out the DOS disk and insert your Multimate disc, it being the first PC word processor of any note. So, enter MM or something at the A: prompt and it loads. It was green screen, no graphics, and so you created a document, a blank space to type in. When you wanted to save your work, insert a blank floppy disk in drive B: and save it thereâ€¦as long as you had remembered to format it using DOS before hand. When you are done, take the third disk with you with your work on it, and leave the other disks for the next user.

Given all this, the PC did not really get a lot of users, but my use of a PC was about increase dramatically.

Memories of IT - could computing be fun?

2009-09-11T13:04:00.003-04:00

The time periods covered in the previous posts overlap in some cases, so the PC did not just appear in a poof of smoke where I was working, totally unexpected. Lets pause and talk about computing for fun.

I am guessing the first CRT most people of a certain age used was on a video arcade game. Before that, there was pinball and other physical games like baseball (machine pitched a ball and you hit it with a bat in the same way as pinball flippers.) I played these games in many places as a youngster. A bowling alley on a Lake Huron beach comes to mind, and a few trips to the UK where I saw games where you dropped a coin on top of a whole lot of other coins in the hope it would be the one that tips that whole pile of coins into a slot that delivered them to you; my first exposure to gambling, I suppose; And there was skee-ball, trying to win coupons to cash in for cheap toys/trinkets. ( I mentioned earlier about playing Adventure on a teletype at university, but was really only available to students of the time.)

Then the first CRT-based game(s) appear. Was it Pong? Wikipedia would tell us, I guess. What I remember from the 80's was the arcade in the mall next to the office where I first worked, and it had about 20 machines lined up. Here is where I first learned that my eye-hand coordination skills were average or worse. All these games were based around scoring a level of points to get free games (taken from pinball I suppose) or move to the next level. I could get a free game or two, but would crash and burn not long after that point. Some of my-coworkers could play a game for hours on one quarter. They also set up tournaments for co-workers, which I did not enter.

The main game I recall of this period was the first Star Wars game. It was a first-person flyer-shooter, you were Luke in your fighter attacking the Deathstar; you started by battling Imperial fighters, then to the surface to get past tower cannons, and if you survived to that point, you flew into the trench to shoot the bomb down the hole while Darth Vader tried to shoot you down.

If you succeeded, you would start all over again at an increased difficulty level. I recall I managed to get through the first level and into the next, but never farther. Then a guy I worked with would step up and go thru 3 or 4 or 5 levels, and might just walk away before losing, because lunch hour was over. I felt SO inadequate as a game-playing male.

(This reminds me that at this point, really eccentric characters were still something you could be working with --- at the company, they were programming whizzes or knew stuff nobody else knew; so long hair or dread-locks was OK, plus guys in weird suits with fedoras, and more, and they were all great game players; but they all moved on at some point, maybe to develop games.)

Any way, the graphics on the game were neon lines on a black background., simple but effective for a game set in space. The soundtrack was the familiar movie score, with clips of things like Obi-Wan saying "Luke, use the force!". It was fun, I played it a lot, but not once did I walk away because my lunch was over...

Memories of IT - early 80's - my own terminal, plus email and laser printers

2009-09-10T12:01:00.004-04:00

So, I and several other programmers are assigned full-time to the development project. To be productive, management figured out we needed our own dedicated terminals, so we got them, and so did everyone else in the department over time.

A major long-term impact of this was that now we could move from semi-open floor space, where terminals could be shared, to full-on cubicle farms, and that's what happened. Its funny now, because lots of offices are trying to get back to open space, and being trapped in a cubicle is treated as torture, but we were all thrilled when we each got our own 3 and half walls. I think this has carried over into my choices in housing; open-concept and high-ceilings means wasted space. I want walls, doors, and each floor of my house to cover all the available space.

What else was going on about this time? We got internal, mainframe-based email. Up till then, we were still using triplicate memo forms to hand-write messages and send them by inter-office snail mail; can't say I missed that very much, but email was charged for internally for its use of external mainframe cycles, so some departments refused to use it because of that cost, and it usually turned out to my users; but the email worked well, just still text on a green screen and only within the company.

Around this time the company bought its first laser printer for the mainframe, producing excellent quality printing on standard letter and legal paper. What you would do is insert printer commands in your code to produce reports that looked good. We also started typing memos and documents in TSO PDS members, and you would add printer codes that specified font, bold/italics, spacing and more. I think this when my typing started to get faster because of constant use, although I have still never learned how to type like a typist would. (They didn't teach typing to boys in high-school back in the 70's, that was for girls, who also learned shorthand, so they could go right out there and be a secretary! I have to think shorthand really has to be a lost skill by now.)

But even with mainframe email and laser printers to dazzle us, lurking out there was that next great paradigm-shift: the IBM PC.

Memories of IT - A New In-House Development Project

2009-09-08T11:28:00.001-04:00

So, a couple of years into being a Programmer-Analyst... it's still the early 80's, back when jobs had numbers after them, so you would start as a PA 1, progress to PA 2, and so on. Progression also meant raises along with annual increases. I would say this was the period of my career, unique to the time, where my salary grew the fastest. No one had invented bonuses based on company success, you made what you made without concern for company profits, while realizing that low or no profit was not good for job security.

So, a couple of years in, the Corporate Systems department gets a new development project! This is full in-house development, PL/1, IMS DB/DC. The company had been using a system similar to the mortgage system I have described, but for securities: stocks, bonds, money markets, etc. I was not in on the process that led to the decision, still being a junior programmer busy on current projects, but looking back now it must have been a reaction to the realization that every-other-night batch processing was not going to be good enough for stocks and bonds trading. So, this was going to be an online system, where the trades on the markets would be captured right after they occurred. It was not a trading system itself, nor was it connected to one, so the traders were going to record what they did in this new securities administration and control system (more on how that worked out, later).

As I mentioned earlier, the core Individual Insurance Systems were already online using this technology, but it would be the first such system in a Corporate area. Our senior programmer/designer/architect took on the challenge of building a trial online system first, to show it could be done in Corporate Systems, It was an easy-to-develop structure he came up with.

Most online systems have one program for each screen used in the system that handles both out put to the screen, and receiving input from the user. I saw this structure as awkward, as it could be tough to discern which part of a program was being used at any one time. Our architect devised a master control program that would, for example, discern what screen had been just used by the user and pass its input to a program built to process input from that screen. It would do all the editing and, if there were input errors, it would pass that information to a program built to send data and messages to that screen, which would do just that. The user has the response and does what they need to do, hit enter and the whole process starts again. Once the input program is OK with the data its has received, it will then do one of many possible things defined for it; for example, the user may have indicated they want to navigate to another screen, so the input program would pass control (and any needed data) to the output program for that other screen, it does what it does and sends data out to the user, etc. etc.

Just want to remind the reader that this is still a mainframe, green screen system, so next time I will recall how we actually built it, and the good and bad things that happened.

Memories of IT - early 80's - Computing Goes Online

2009-09-03T22:15:00.002-04:00

So, I am in a department of 25 people, all working with coding sheets, until one day, a couple of terminals appear. They are put in the middle of the department, so each person has to schedule time to use one. This is when I first used TSO seriously, using both the command line and the menu-based SPF function, I learned what Partitioned Data Sets were, and how to create files online and allocate space. The main reason to use them was that you could extract a program from the Librarian tool, edit it in TSO and then put it back in Librarian; look ma, no punch cards!. This led to the first "religious war" I saw; if you used Librarian in batch mode, it would track all the changes made to the code, providing a history of changes over time. However, if you used TSO, that updated code would be placed back in Librarian like it was a new program, no history recorded. Well, people were aghast that the history was going to be lost, how could you debug a program with knowing that history, etc. etc.

The fact that I don't remember if I cared one way or the other is the first indication that I have almost never "chosen sides" in debates like this. I might express an opinion, or actually be the analyst defining the pros and cons, but once a decision was made, I was never the person who would be whining 6 months later "we should have done it the other way..." You gotta go with what's been decided, otherwise it's time to move on.

In this case, TSO updating won out and Librarian was phased out over a couple of years. The corollary technique to change history was commenting your program code, inserting text at regular intervals to describe what the program was doing; so, it was decided that significant changes be noted as comments too.

What this led to was a need for more terminals. Over time, we got enough to have one for every two people. It sat on a swivel table between desks, so you could move it to use it when you had something to enter; the other person would do other work until their turn with the terminal came up again. This would still be in the early 80â€™s, just before a big new project that would change how we worked some more...

Next Time: A new development project

Memories of IT - early 1980s - Starting to work...

2009-09-02T15:08:00.002-04:00

So what was my actual first work? Maintenance, making changes here and there in the Mortgage system. Sometimes there would be a need for a new report, so that might be written from scratch, but often it was take an existing report/program, copy it and change it. Less often, I got to create something totally new; I recall an accounting reconciliation function I developed, matching detail mortgage transactions to GL entries; it was big, intricate, and I was quite proud of it. All of this was done under the direction of an experienced programmer, a nice woman whose name I really wish I could remember, because she got me off to a good start, but left the company not too much later.

Looking back, the main maintenance work is where I first started doing more analysis than coding. Figuring out what the system was doing and how to change it to do what new thing was being asked for, that took more time and effort that the actual coding changes.

I was also lucky to start out in area that literally supported more systems than there were people in the department, so I got to work on many applications over time, from Real Estate Management to Shareholder Reporting to IT Chargeback. I contrast this with the company's main individual life insurance system, which was huge and had a whole department just for its care and feeding.

Other things to note about this period, first half of the 80s:

All the systems in use had been developed in-house
Batch systems were on their way out; the life system I mentioned above was on-line, using IMS DB and DC. This led to the first down/out-sizing I saw in my career; the internal keypunch group was phased out. The current staff were offered positions with an outside company that continued to do the same work for Crown while it was still needed, but with the obvious expectation that it would be needed less and less over time. At some point, the cards themselves were phased out, with the data being entered in files that mimicked the cards, and those files being used as input to batch jobs.
The technology/tools used by programmers was also changing; more on that next time.

Next time: Development goes online...

Memories of IT - 1980 - My First System

2009-09-01T16:31:00.001-04:00

So, about 6 weeks of PL/1 training, coding some pretty big programs (what they actually were/did, I don't remember) and I am ready for some work. The system I start on is for Mortgage administration; the company loaned money to both individuals and businesses, although the individual business was wound down by the mid-80's. This also meant staff mortgages as a benefit, which I and my wife eventually took advantage of. (oh yeah, got married in 1979 too; she was not in and never has been in IT, a good thing in the long run I think).

So, the Mortgage System, MTG for short. It was a batch system, in PL/1 but not with flat files or VSAM. Someone earlier in the decade had written a little DBMS system that this and other systems used. It was hierarchical, so each mortgage was a root record and had children records of various types, like for the payments collected; this was the Master File. Transactions for the system were written on custom input sheets that went to the keypunch group. All the transactions were gathered up and run against the Master File overnight. The input transactions would be sorted by Mortgage Number/ID, and the main batch program would process Master and transactions in Number order. It would skip past Mortgages that had no transactions, and then apply the transactions against Master records that did. It ran every other night, which gave the business time to look at output one day and then code new transactions the next day.

As I look back it now, it was a pretty good system. Since it was all batch, looking at info for a Mortgage meant printouts. To save paper, the system used microfiche. A printout for each mortgage was put on fiche to begin with, and then each time a mortgage was updated, all the updated ones would get a new-printout on a new fiche. The fiche was numbered, and there was one fiche that had an index of which number fiche to find a mortgage printout on. That index was recreated after each batch run, and would point to the new fiche as needed. Once a quarter, when a lot of new fiche had been added, the system would print a new set of fiche, and the process would start again. There were also monthly jobs for reports, and an annual run for more reports and some housekeeping, like purging paid-off mortgages from the master.

I suppose everyone has a soft spot for their first system, like their first car (mine was a 68 Ford XL) or other firsts. The system would not last forever, but that is another post...

Next time: Starting to Work

Memories of IT - 1980 - Learning to code for real

2009-08-31T10:58:00.002-04:00

First day in a real office, wore one of my two jackets and one of my 4 ties, business casual is still decades away. I join the Corporate Systems area within IT (probably called IS at the time), and a team within that area supporting investment systems.

As mentioned before, Crown hired people of all disciplines as programmers, so it starts everyone on a programming course, overseen by one of two IS instructors. I learned that PL/1 code needs to be structured and follow some rules if other people will be able to read and maintain it, so I am quickly cured of some bad habits learned in school. Structured PL/1 means no GO-TO statements, rather one should use procedure calls to sub-routines, with parameters for passing data back and forth. DO statements are another favored construct, both DO x TO y and DO WHILE statements.

Programming technology? Coding sheets, which you gave a group of keypunch people. When ready, you put the deck in a box outside the local operations, who ran it through the reader. The reader and printers are connected by a dedicated line to Crowntec, where the mainframe(s) lived, somewhere in North York.

Given programs of any length, we did use a source management product called Librarian; your card deck would be saved as a Librarian entry/member, and after that you would used Librarian commands to add, delete or replace lines in the entry, again through running punched cards, but just the ones you needed.

Part of running all these decks were cards for JCL, mainly a JOB card with your account and ID, and all the needed PROC statements and such. I think Librarian had JCL in it, but the memory is weak. TSO and partitioned data sets were out there too, but more on that later.

Next time: My First System

Memories of IT - 1979 -Finishing University and Getting a Job

2009-08-28T11:55:00.002-04:00

Middle of the school year, employers come on-campus to do job interviews. It is still the olden days, so you had to hand-write job applications for each company on a standard form, could have used copy-and-paste....

I recall 3 interviews; I positioned myself as being a guy who wanted to work on real business systems rather than pure techie stuff like operating systems, fairly prescient I think now, but some of the interviewers viewed themselves as techies, so it did not sell well to them. Of course, I had no idea what a "real business system" was. UofT did not have a co-op program, so I had not worked in any IT department; my summer job was not in IT, but I kept it because I could work part-time during the school year as well, and I needed the money year-round.

I think it was an interview with Bell where I hit the techie reaction most.

General Motors was hiring, but their career path for programmers was that you had to start as a computer operator doing shift work. Neither thing appealed to me, but they gave me a second interview, which meant I had to drive out to Oshawa, east of Toronto, where the interview include a tour of Operations. I remember only a whole lot of printers, so feeding them paper would be the main work. GM solved this problem for me by not offering me a job, I think they sensed my reluctance...

One of the remaining interviews was with Crown Life, a middle-size Life & Health company, located on insurance row in mid-town Toronto. The interviewer was more 'touchy-feely' than others, wanted to know more about me as a person, not just as a set of skills. Their next step was to invite you to the head office building for a tour and to write an aptitude test. There was no Operations room to see, as they had already spun off their computer operations to a separate company, and Crown Life was now one of many of its customers. They also gave the aptitude test to non-CSci majors, believing that programming was a skill people with other degrees could master as well. Anyway, I passed the test, got a job offer that actually paid more than others I had seen, although the annual amount would not buy a compact car today. I also liked that they were a PL/1 shop, as I hated COBOL. So, I accepted and started in May 1979...

Next time: Learning to code (for real)

Memories of IT - late 70's - Finishing University

2009-08-27T12:00:00.002-04:00

Moving into the later years of university, it is true in any major that the number of people attending the the 3rd and fourth year courses reduces to a core group. So, I spent a lot of time with such a group, and now look back and wish we had Facebook or something, because I wish I had somehow maintained contact with a lot of those people.

In class, I found myself doing well in more commercial topics, like databases, and not so good in more theoretical topics, like Artificial Intelligence (since AI never really took off the way it was promoted, I don't feel too bad about that). So, it was clear that I was not destined to be a Computer Scientist, emphasis on the 'science'.

In the meantime, being more senior meant access to slightly better technology. One course had us using interactive terminals tied to a PDP computer, but the terminal was tele-type. It printed what you typed, then you typed "enter" or something, off it would go to the PDP somewhere, and it would then comeback and print-out its response. I think I used this to program a B-Tree type of DBMS, which I recall I was quite proud of and got a great mark, but the details have not remained in memory, and the paper print-out disappeared at some point as well.

What this also introduced me to was the first computer game I had seen and played. It was called Adventure, and if you had a user account balance that more than met the need of your course-work, then it was time to play Adventure. It was a text version of what you would recognize as Dungeons and Dragons, or others of that ilk. It typed out that you were standing at the edge of a hole in the ground, you would type 'jump in hole', it would type what you see in the hole, like a key on the ground, you would type "pick-up key" because you would need it later on... turns out I suck at this kind of game, so no D&D play (or WoW) was to be found in my future.

There was also some TSO to be found. If you took on the job of student advisor, you got a TSO account, as long as you sat in a room near the card-reader and helped more junior students with their course-related questions. As was the nature of more senior people, we looked down on junior folks, especially those taking Programming 101 but who were not Comp Sci majors; much sneering accompanied the grudgingly provided answers. I cannot remember using TSO for anything except a text-based golf-game.

Next Time: Getting a job...

Memories of IT - 1975 - Starting at University

2009-08-26T20:28:00.001-04:00

So, I am off to college...during the day, still living in my parents' basement off campus.

One coding course to start: I like PL/1, dislike COBOL, can't seem to fathom LISP.

Take college level Calculus and Algebra: how could something I was so good at in high-school turn into something I loathed? lucky I didn't choose to be a math major.

Other courses come and go, always looking for the easy course to fill the schedule. A course in Canadian Economics was taught by Mel Watkins, then known as a real left-winger in the NDP. His statement in the first class was that a professor could change anything about a course he wanted to, except the name... so he proceeded to teach communist economics, can't say it has come in handy since, but Mel was just fun to listen to.

Still doing coding language courses, the environment is still primarily punch cards. You create your deck, and then get in line at the back of the room to feed them to a card reader, and then move down the line to a printer which spits out the results. The paper is the old style, wide, white with green lines, holes on the side for feeding the printer. So, you only have so many runs before the assignment is due...

A separate room next door has tables to sit at and work, shoot the breeze with other students. The big issue was that most people smoked then, but a movement was started by the minority to ban smoking in the work room. Looking back, I can see why, the air in the room was blue, but as a smoker in those days, I didn't care.

Speaking of smoke... there were a couple of card-reading machine rooms on the UofT campus, one in the sciences building that I frequented, and another in the main Engineering school building. Well, the latter building suffered a major fire one night, and firemen were clearing the building when they came to card-reader room. With smoke filling the room, students told the firemen, "I just need to run my deck one more time (!)"

Memories of IT - 1975 - why would you major in Computer Science?

2009-08-25T12:38:00.001-04:00

Last year of high-school, Toronto Canada, 1975... can I recall what was driving me?

Other than my "Fortran Programming" course, my focus is on sciences (physics and chemistry, but not biology) and maths (calculus, functions), a little English Lit, and Music, as a drummer.

I am 18 years-old, shoulder-length hair, playing drums in a garage-band, I momentarily scare my parents with the idea of skipping university and trying to be a rock-and-roll star. However, the band never gets out of the garage, I can't sing or write music, and the number of drummers in the local union is large. I was going to be(and eventually would be) the first person in my family to attend university, I had the marks for it, and my analytical bent won out, seeing a degree as something that would my life more successful.

But what would I take? Thoughts of Law were entertained, but then I looked through the course calendar for the University of Toronto, and there was a whole section/discipline on Computer Science. Well, I was the master of Fortran programming, and computers were becoming more known in general as a source of future careers. I elected for a less theoretical program, with a commerce/business minor, as the road to future employment bliss, and just like that, the next 35 years were based on that decision as a teenager. I applied to UofT and other major local schools, was accepted most everywhere, and signed up for U of T for the fall of 1975.

Next Time: Starting University.

Memories of IT - 1973 - High School Computer Science

2009-08-24T13:42:00.001-04:00

Fall 1973, my first introduction to coding sheets and punch-card machines. The class is ostensibly about Fortran programming, but the teacher was barely there. he would write a few keywords on the board, how to define a variable, write an assignment statement, then gave us a problem to solve and program. Most of us looked at each other and said "what the..." but one brilliant guy could figure it out and could be convinced to share some of it with the rest of us.

Once I got a handle on what the teacher was really asking for, I was OK at the basic coding and debugging. We punched cards at the back of the classroom, which were put in a box and taken out of the school to the school board office, where the "mighty computer" lived. Somebody there ran the cards in a batch run, and we got the cards and a print-out back the next day.

If you got the thing working, you got a good mark, and I don't remember any exams, so it was good option course which let you focus on the core math, sciences, english and such that filled up the rest of the day. So, I took it again the next year. I can still recall the classroom and the teacher, but not much at all of what I produced over the two years. I think I learned about GO TOs and DO loops but can't be sure... but it left some kind of impression, because I took it up as my major in university ...

NEXT: Majoring in Computer Science

Memories of life in IT

2009-08-22T20:42:00.001-04:00

I have just been doing the math, and I have been doing IT Projects for 30 years now (I started young...). It made me think that I do have my share of experiences that, if written down, some small number of people may find interesting. Seems to me a blog is great for that.

I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.

But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most welcome.

Where does it start? Spring 1972, 10th Grade ( or "Grade 10" as we called it in Canada), looking at optional courses for 11th grade in the fall, and my eyes come upon "Computer Science"; sounds interesting, what the heck...

Complex Adaptive Systems: Why most Information Systems don’t Measure Up.

2009-07-21T10:22:00.001-04:00

Complex Adaptive Systems, or Complexity Science, is about a lot more than Information Systems, we human beings being a prime example of such complexity. Wikipedia and other sources provide all the details you want on this topic, but one view of it that has stuck with me over the years is the difference between ‘complicated’ and ‘complex’.

Roughly speaking, a complicated system is what it sounds like, a system that is not simple and not intuitively understandable; however, given time and effort, you could analyze and identify all its parts and pieces and describe the whole system. The key is that it is a fixed system.

In contrast, a complex system cannot be analyzed and described as above because it is changing over time; analyze it last week, and again next week, and you will get two different descriptions. For decades, we have been fairly good at creating complicated information systems, but complex was and is rare, if even considered. Instead, what we have in IT is the Change Request, the Backlog, the up-coming Maintenance Release.

The problem has been our creating of information systems based on the needs of an organization at the time we asked. We were guilty of hard-coding the business process and rules (while probably not recognizing them as such) and delivered that code in working order, to be told that the business wasn’t doing things that way anymore; or worse, the business would keep this to themselves and start creating the first of many ‘workarounds’ needed to get past the system limitations and get things done. In either case, the situation would deteriorate and then the change requests would start coming.

Now, hind-sight is wonderful, and decades of hard, well-intentioned IT work should not be scoffed at; this has been a difficult realization to come to, common in many disciplines where complexity science has tussled with older paradigms; and the realization did come together in pieces over time as parts of the problem were recognized and new technologies & tools were developed to help. The now ubiquitous Database Management System came from realizing that lots of flat or indexed files processed in various batch jobs resulted in lousy information, and certainly weren’t going to work in on-line transactions, and even then we had to work our way through competing designs like hierarchical systems before the relational systems we use today emerged.

However, when it comes to complexity, data needed by a business is comparatively stable; it is how the data is used that changes more. Take a typical business process of handling a loan application; today the big loans go to Fred to process, but next week they go to Anne. That is the kind of change you cannot make to a hard-coded system fast enough to support the business. Beyond that, consider the rules that drive a process, such as loans over $100,000 need to be approved by a VP; and starting next week, it is changing to loans over $75,000.

This kind of complexity has finally led to some changes and new tools to help the business. First out of the block has been Business Process Management tools (BPM), which originated when imaging systems changed offices from moving paper around to moving units of work. More recently, Business Rule Management Systems are being implemented that move the changing of rules from the realm of the programmer to that of the business expert.

Will these tools be enough to move us from complicated, maintenance-heavy systems to truly flexible complex systems? There is no denying it will help; they will certainly solve a lot of old problems, so that we can move on to solving newer, better problems and what more can you ask for.

Once a project is started, finish it.

2009-07-07T17:37:00.000-04:00

No principle screams from the page to me than this one, yet rarely have I seen it implemented.

I have worked under various managerial styles, but it boils down to two approaches for me, integrated or divided. All enterprises of any size do need to be composed of many organizational units, but that is to divide up the people into manageable groups; it should not divide the enterprise into separate fiefdoms. Just think how many times you have seen or been part of a re-organization, and then think about how many times that has changed the actual work you or anyone else does; the latter adds up to just about nil.

Consider a complete enterprise, with all the usual line and staff functions ; ask anyone in that enterprise how it is structured to do its business and you will probably be shown an org chart. The usual hierarchy of boxes and lines, from CEO down to the base units, is the business graphic that is the oldest and most commonly used. However, why does it have to keep changing? That’s because people are not automons, they need to be grouped in ways that maximize their contribution to the enterprise, while hopefully having job satisfaction and a boss they don’t loathe; and since people come and go, and since people can change over time, any one instance of an organization (as represented by an org chart) will be become sub-optimal as time passes, so re-organization is needed, and it is a good thing if it re-energizes people and re-marshals the enterprise to be its most effective.

The problem is when management believes that the org chart at any one time also represents how the work gets done. Worse yet, they also use the org chart as the basis for changing/improving how the work gets done. This is the ‘divided’ managerial style I mentioned earlier, and it directly affects how the enterprise carries out projects.

At any one time, an enterprise has certain amount of capacity to implement change; the main numbers are how many people there are to do projects, and/or how much money is available to hire outside people to do projects. These numbers are a primary input to that common-place activity of annual budgeting/planning; these numbers are limited/finite, so managers need to decide how to best use them. In the divided managerial style, each major tree below the CEO on the org chart is allocated some portion of those numbers; if you have 10 people available for projects, the number used may be 120 person months. So, Sales is allocated 20 months, Operations gets 40, Finance gets 35, etc. Management may come up with what it believes are equitable/effective means of divvying up the number beyond just dividing it into equal units, but that is a sham; this is further reinforced by the sham idea that if each unit operates and changes successfully in of itself, then the total of all the units’ success will equal the overall success of the enterprise. Does your company have internal charges between departments, often referred to as ‘funny money’? Then your company is divided, because all that funny money means nothing to the bottom line of the enterprise.

A divided approach is a problem when projects are used to improve the business, because projects change the work, not the organization. Take an important and common business activity, order fulfillment. If you trace the work from when a customer first orders a thing or a service, to when its delivery is complete, many (many!) org units will be involved. So, if each unit independently attempts to change/improve that stream of work, they will either overlap with other units or duplicate what other units are doing without knowing it.

The main result for IT is that each org unit will want to use its allocated resources to get its own projects done. So, irrespective of their overall value to the enterprise, a number of projects will get initiated. This will result in overlap or duplication within the systems IT delivers, assuming the systems are delivered. IT management will be faced with conflicting demands on their limited resources, so only some sub-set of the projects will be proceeding while others wait for resources. This leads to projects stopping for a while when they get to a point where they need new types of resources, and then have to start up again when those resources eventually become available.

So, irrespective of the method used to divvy up project resources, the ‘divide’ approach produces an ineffective and wasteful projects environment. The solution to this problem is to move to an integrated managerial approach.

An ‘integrated approach’ recognizes that an enterprise is a team brought together to operate a business, not a collection of independent fiefdoms; a CEO that recognizes and leverages this approach also knows that projects to improve the business belong to the enterprise, and almost always impact multiple organization units. Given this recognition, how an enterprise organizes its resources to carry out projects then will (or should) be tailored to the mix of people involved, just like any other aspect of organization. This could be anything, from ad-hoc teams to a full Project Management Office. Any good structure will do, as long as the enterprise view is maintained.

And that’s all I have to say about that.

IT Project Cost-Benefit Analysis

2009-07-05T20:46:00.001-04:00

When I did my first Cost-Benefit Analysis for a major project, I had to work with an spreadsheet expert to to do these calculations; now you can probably download something for free or a nominal fee that will do basic and advanced calculations. The key things these tools need is the two dollar values, cost and benefit, and the length of time of the analysis. The latter is usually defined by accounting standards at your company, and the most popular time periods used are three years and five years, often based around your company’s depreciation procedures/periods.

Given that, you can usually get calculations like:
• Break-Even Point, the point in time when the benefits realized exceed the project cost
• Various rate of return and yield values, like IRR.

These calculations may be used to determine if a project passes a funding hurdle; its not enough that a project makes money, but it has to make more than investing the equivalent dollars of the project cost in securities or other investments.

After all this is done, a project can now proceed into the gating process to see if it has enough expected value to warrant its being initiated and carried out. Of course, if your analysis has determined already that the project does not have positive return or does not surpass the hurdle rate, you can stop now and move onto the next project idea. Determining that a project is not good for the business is just as valuable as finding those projects that are good for the business. Resources should not be wasted.

How do you know which IT Projects to do? Benefits…

2009-06-29T23:12:00.001-04:00

Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. Benefits, however, are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.

In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.

In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived this as eventually leading to lay-offs, this could kill a project because you almost always need those people as the business experts for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.

However, automation of manual work as a benefit could usually be quantified in dollars in potential saved salary costs. The problem today, however, is that all the obvious automation projects have probably already been carried out at your company. This leaves smaller or less obvious cost-cutting projects, or projects that are expected to increase revenue/income.

The question becomes: how much will this project contribute to increased sales of products and/or services. This is difficult to predict, and most business people are leery of attempting to do so. Just like IT Project teams are held to a project estimate or be considered late/costly, business people who estimate revenue increases can be held to task if it is perceived that the expected increase did not materialize. An interesting corollary development is the increase in the number of companies that are evaluating projects some time after they complete (six months or so) to see if the promised benefits have been realized. This can make business people even more wary of putting their names to what is and should be treated as an estimate.

In the end, however, some dollar value of benefits needs to be proposed and agreed to, if a cost-benefit analysis is to be performed. All I can say here is that, like all estimates, stating your assumptions and having them agreed to as the basis of your estimate is crucial. If reality proves that one or more assumptions turn out to false, then everyone involved in the project shares responsibility.

How do you know which IT Projects to do? Project Costs

2009-06-24T00:20:00.000-04:00

A typical IT project will involve IT people resources, of course; analysts, designers, programmers, testers, trainers, etc… The titles may be different at your company, but the people will be performing these roles. The question, of course, is how much of the valuable time of these people will be needed, and how much that does that time cost? This is when the estimating begins.

Estimating the cost of IT projects is a whole discipline in of itself. I highly recommend the writings of Vitalie Temnenco on this topic, such as “Software Estimation, Enterprise-Wide - Part I: Reasons and Means (June 2007), at

http://www.ibm.com/developerworks/ration… ,

where the author is described “an architect for the Ontario, Canada government’s Workplace Safety and Insurance Board, where he provides architectural mentoring on implementation projects and helps teams embrace RUP and the Enterprise Architecture concepts.”

In this article, he covers the most well-known techniques, classifying them as top-down or bottom-up, and continues on to cutting edge techniques like neural networks and Dynamics-based techniques.

My experience with estimating has led to always determining up-front how close to accurate an estimate needs to be. When using cost estimates as part of a gating process, I find a reasonably supported estimate done in a short time will suffice. I have heard an initial estimating being referred to as “t-shirt sizing”; is it small or medium or large or extra-large, etc. Even this needs some context for a company, usually by classifying past project actual efforts the same way.

This helps with the simple approach of “Is this new Project X the same size as a previous project we have carried out?” Assuming your company has kept the metrics about previous projects, and that is a big assumption, you can then extrapolate the size and cost of any similar new projects.

True, some one has to lay it on the line and decide if a new project is reasonably similar to previous projects, and the person doing that should probably define some assumptions about why they believe so. This allows the decision makers to agree with or challenge the assumptions as needed, until all are agreed on the assumptions and accept the resulting estimate.

If you have no metrics/history to use, you may need to do some project planning to define the tasks likely to be carried out. Again, a whole other big discipline exists for project planning and management, and use of techniques of like Work Break-Down Structures (WBS). A simple web search or a visit to the Project Management Institute (PMI) website will get you started on that as needed. The only thing I emphasize in this approach is that as much as possible, people who would do the work should help in defining the necessary tasks, and then they most certainly should do the estimating of effort (usually in hours or days) of those tasks. They know best what will be needed, and will make sure they are happy with the estimate because they will likely have to work to that estimate when the project starts.

This planning approach must also make assumptions, mainly about what the project would deliver that will provide the expected benefits, and that may not always be very clear when a project heads into the gating process. So again, define assumptions that the decision-makers will accept and then go from there. In the end you will have a number of effort hours or days, and then you need an accepted price for an hour or day. Some shops will use a flat rate for all hours, while others will group the hours by role or seniority to get a range of rates. In either case, you multiply the hours/days by the price(s) and you have a cost. Other costs may be involved as well, especially one-time purchases of equipment or software needed by a project.

To go along with this cost, you will need an estimate of elapsed time for the project to execute and finish, because most benefits will not be realized until a project is over, and (later on) we will want to compute a present-value of future costs. More assumptions are needed; how many people will be assigned, what work can be done in parallel, etc. If you have used a project planning approach, you will have the advantage of defining many of these things already and will have come up with a project duration along with the project effort.

How do you know which IT Projects to do? and not to do?

2009-06-21T23:11:00.001-04:00

Any company, and its IT organization, has a limit on the resources it can use on projects, so it has to choose, and choose wisely, from all the ideas and opportunities it may have before it at any one time.

The term that has emerged to describe this is Project Governance. The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.

It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development. As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the company.

The key question then is: what projects does the Enterprise consider to be most valuable? And the follow-up: how does it determine the value of any one project, so it can be evaluated against ‘competing’ projects?

In private enterprise, the single common goal is sustained profitably , through a varying combination of revenue increases and cost reductions. Projects are used to change how a company operates in the expectation that such change will deliver the desired revenue increase or cost reduction, and deliver it such that the value of the changes is not exceeded by the cost of the project itself.

So, we have two aspects of a project that will usually be used to determine its value:

1) Its impact on revenue or costs of the enterprise, commonly known as Benefits.

2) The Costs of carrying out the project (which some refer to as the ‘investment’)

Given these two dollar numbers, which is what they should always boil down to, you can then use them in one or more forms of what is commonly called a ‘Cost-Benefit Analysis’. However, neither number just appears out of thin air, and any numbers you do come up with will never be exact, because estimating is involved.

Next time: getting Costs and Benefits for IT Projects.

David Wright

http://www.authorsden.com/visit/viewwork…

Pick The Right (IT) Projects for the Business

2009-06-01T23:57:00.000-04:00

IT Projects have rightly earned the reputation over the years as places where lots of money goes in and no value comes out. We are all aware of the CHAOS studies by the Standish Group that show most IT projects are also usually late, and a large number are never even completed(!).

How did this happen? My view is that, way back when, computers were first used to automate rote manual tasks, and the results from these projects were valuable and easily seen as so. This led to the belief that automating most anything was going to be good for the enterprise but, as projects moved into more complicated/complex aspects of the business, the returns of pure automation began to diminish. Unfortunately, it was still assumed that the value was there, and it was a complete assumption; actually determining what the value was to be was done only rarely.

Early computer projects really were run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well, so the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.

So, projects proceeded into more complicated areas of the business, and they started to break down, some failed, and now Management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable).

But that is the history: all the easy automation projects have long been done.

Next time: how to choose the most valuable IT Projects…

Which projects should you focus on first?

2009-05-23T19:09:00.002-04:00

Continued from:

“Get Your Projects Under Control…”

http://businessanalysis56.blogspot.com/2009/05/get-your-projects-under-control.html

If you have too many projects going at the same time, pick the best ones to focus your resources on: but how do you do that?

If no other factors are in play, choose the projects that most closely look to be near completion. This can be difficult, given that “90% done” syndrome ; you may focus on a 90% done project and find it is more like only 10% done in reality(!), at which point I would drop it and move on to a more promising project.

Other factors can be applied in selecting projects sub-set; they depend a lot on how much information you have on your projects, and can include:

- Business Value or Return On Investment: if you already have some notion of the value of a delivering a project, especially a cost-benefit analysis, you can try attacking the projects with the highest value if that is something your business management will appreciate. Many companies are good at defining value or benefit up-front, but only the better companies take the time after a project is complete to confirm if the benefits really were realized. If you company does not do this yet, suggest they start, but avoid this factor for selecting the projects subset until they do start.

- Project Priority, which can be determined based on a combination of Business Value and/or other Project Drivers. This is often a weighted calculation where values are assigned based on how well a project addresses items such as ‘increased sales’, ‘improved decision-making’, ‘better customer service’, etc. . Each project has a priority value to compare to others, and highest-priority projects are initiated first.
If you have a Priority value assigned for your projects, but it really hasn’t been the key factor in initiating projects, then start using it; that’s pretty obvious, I know. What is more likely is that priority did play a part in initiating projects, but has not carried over to decisions made during projects. If your projects are now executing out-of-priority order, see if re-ordering them will help in faster delivery and increased business value.

- When all else fails, Ask. (Or just start with Ask). It will be no big secret if you have many projects underway with no ends in sight. It is also likely that many current stakeholders may not have been involved when some of the projects were started. So, you can meet with these stakeholders to determine what their current priorities are and which projects are of most value to them.
The usual issue with this approach is: who should I ask? In a perfect situation, I look for the person highest in the organization whose span of control covers all departments who sponsored or are impacted by the projects. However, this person could be senior enough in the company that they may decline to help you, preferring to delegate to their reports. Querying and meeting with this group may give you the priorities you need; or, it may illustrate any politics or power struggles that are on-going, for which you may be able to facilitate a resolution or at least a compromise…or not. In the latter case, it may be necessary to escalate this back to groups’ common manager for resolution.

So, one or more of the above factors may assist you in identifying the best sub-set of projects to first target for quick completion. If no strong values or priorities can be discerned, I would default to those that can finish the fastest.

Get your projects under control...

2009-05-15T23:29:00.001-04:00

In these trying times…or some variation of that…is the first line in every other article or post of the past 6 months, and I am getting really tired of it.

What usually follows is advice to get things in order, whatever the thing of interest is, while focus is elsewhere and before it turns back to you. However, if your thing of is interest is the slate of current IT projects in your organization, there indeed may be some opportunity here. It’s time to get positive.

Do you have a lot of parallel projects? Probably figgting for the same more limited (than ever) resources? Are they all target-date challenged, i.e. all late or later than late? Now is the time to get them under control.

The absolute first priority is to wind-up as many of these projects as possible, as soon as possible. This sounds like common-sense; it is certainly sensible, but not at all common.

No rocket-science here, you need to allocate all your resources to a subset of the on-going projects, get some successful project deliveries, and then look around for new opportunities. If you have a large slate of current projects, you may need to do this again (and again) for another subset of projects. Keep doing this until the number of current projects no longer exceeds your capacity to resource them, or as close as you can get. Do your utmost to avoid initiating any new projects while cleaning up the current projects.

(Of course, some projects cannot be delayed, especially changes needed for new legislation or other compliance issues. Jump on those immediately and get them done quickly so you can get back to the other on-going projects.)

It also helps if you can manage to identify any existing projects that can be canceled out-right. This will not be totally in your control, as the business unit or sponsor that wants the project done may resist. It is just to your advantage to identify any projects that are clearly no longer needed, and who’s sunk costs should be capped.

How many projects should you focus on as described above? You can’t overload a single project either, without incurring diminishing returns. A rule-of-thumb would be to define the number of people on a typical project team in your shop, and then divide that number into the total number of people you have available for projects. There are many ideas and opinions about optimum team size, usually around 7 plus or minus 2.

Next time: which projects should you pick first?

IT Projects Success - Principle #13: Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables

2009-05-09T01:11:00.000-04:00

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system.

This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assembled.
In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle #11, a Release each quarter is recommended. The business receives what they are paying for often enough to be of value, but not often enough such that assimilation of change is so frequent it causes chaos.

IT Projects Success - Principle #12: Within the three month phase, parcel work into two-week periods.

2009-05-06T22:42:00.000-04:00

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. Are two week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.

IT Projects Success - Principle #11: Partition large projects into 3 month phases

2009-04-29T12:54:00.002-04:00

Continued from:

http://blogs.itworldcanada.com/insights/…

(Want to see more? head over to http://bit.ly/Ypycy )

11. Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

I was lucky to learn this early in the 90’s as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited numbers; MS Project, on the other hand, was readily available and budding Project Managers thought they could now plan the whole world for months or years in advance. What actually happened, however, was constant re-planning as the reality of business change and resource turnover always took their toll. As Napoleon said, “A plan is only good until the battle is joined.” After that, one must adapt to the changes that will always come.

My own experience was on a large project that was broken into a dozen pieces, which were planned separately to a target 18 months away, at which point I was asked to integrate them into one plan while resolving resource conflicts. First thing, we found was that MS Project of that time crashed when you reached around a thousand tasks.

So, it was about this time that some IBM PM consultants were brought on to sort out this mess, and where I first heard the above principle. Yes, you need a plan to get started and to control a project over time. You can even sketch out a plan out over many months to see and communicate the big picture; but, do not commit to any target date over 3 months away, odds are you will miss it. This also means you should do the detailed planning only to the next target date, meaning the full WBS and resource assignment. (At the other end of the detail level, the IBMers also recommended that the shortest task in your WBS should be 2 weeks, no less, otherwise you are micro-managing.)

Once you have a detailed plan for three months, and a high-level plan for the rest of the project, you can add more detail to further target dates as the project progresses, as each interim target is reached or on a rolling month-by-month basis. The level of change in any 3 month period will be manageable, much more than over the whole project.

There is a more recent corollary to the three month principle; the age of the mega-project should be over by now. Any IS project that takes many months or years to deliver the system is destined to fail. Yes, large systems are still needed, but break them into pieces that can be delivered, ideally about every 3 months; longer than that and you start to slide back to the mega-project approach, while shorter than that will not produce enough of the system to be worth delivering to the business. All business works in 3 month quarter cycles anyway, IT should too.

IT Projects Success - Principle #10: Models are better than text.

2009-04-27T21:07:00.001-04:00

10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT). I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presenting a view of the end result to whomever may be paying for it.

At this point, though, let us abandon any other aspect of physical engineering as an analogy for Information Systems development. Software is different; while tools and bridges and buildings have been created to either extend or protect the physical capabilities of human beings, Information Systems are created to extend the our mental capabilities, to help our thinking.

Given that, software can still be engineered, but it is a different type of Engineering. Software or Information Engineering has existed as a known concept since the 1970’s, although anyone who thought to call themselves a software engineer usually incurred the wrath, or at least disdain, of the established Engineering Disciplines and Schools. I am not an engineer, would not claim to be one, but my understanding is that traditional engineering is addressing software within its disciplines. In the future, as software becomes even more critical to our well-being and safety, it may be that those who design and create software will have to be accredited engineers, just like the ones who design and build bridges. I think history shows that quite a few early bridges and other structures were prone to collapse before engineering principles started to prevent it. Software is only a half-century old, so even in the age of internet speed and high change, more time will be needed to bring software in line with other long time products.

In the meantime, it should be a goal all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful ‘objects’ for society to use. The problem is that demand continues to out-strip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.

(see more at http://stores.lulu.com/dwwright99 )

IT Projects Success - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave.

2009-04-23T20:49:00.000-04:00

9. Leave a record of what you have done, so the project will not miss you if you leave.

If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in “quick and dirty” projects where an operating result is produced, but no one else can understand the code that was produced. However, if the contribution involves producing quality artifacts as described in #8 above, there is always a point-in-time record of what has been accomplished so far, which can be used by new project resources to continue the project with minimal disruption.

Last Chance to Participate - Business Analysis Benchmark

2009-04-20T10:51:00.000-04:00

This is your last chance to participate in the 2009 Business Analysis Benchmark study - and access your copy of last year's research. Last year, this research was circulated to a readership of 20 million business and IT professionals around the world. Thousands of analysts and project managers leveraged their free access to this study and used the data to communicate the impact of requirements quality on project outcome.

This year's theme is THE PATH TO SUCCESS. The redesigned survey is shorter, and will help participants to both optimize the tactics needed for improving performance given their maturity level, and better define the business value of continuous improvement in requirements discovery and management.

Completing the survey will take you about 10 minutes. As always, access to the research will be freely given, your personal responses are confidential, and I greatly appreciate your participation in this important industry activity. Use this link to see more about the survey, and get started: http://www2.iag.biz/e/464/kira-TakeSurvey-id-1201992/CPC1M/61635542

Or - type into your browser: http://www2.iag.biz/e/464/2009-04-20/CPC2Q/61635542

IT Projects Success - Principle #8: It’s the Deliverable (that matters), not the Task.

2009-04-19T17:54:00.000-04:00

8. It’s the Deliverable (that matters), not the Task.

The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effective on an average project.

This means that the project work will be divided into many tasks, sub-tasks, etc. . . . Once assigned a task, it is the goal of a specialist to produce a deliverable/result/artifact that can be used by the next specialist to further the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many which spend an inordinate amount of content explaining how to do a task, how to amass all the tasks in Phases, and often insisting that its way is mandatory for success.

What this can lead to is an over-emphasis on the how of IT project tasks, to the detriment of actually completing them with all due speed. Here we see the task that is 90% done for weeks, or the infamous ‘analysis paralysis’ where a project cannot seem to get past Requirements. Ends do not justify any means, but Ends must be delivered.

Can IBM automate decisions? Sure, it's already happening.

2009-04-15T11:53:00.002-04:00

News post: Algorithms everywhere: Can IBM automate business decisions?

http://blogs.zdnet.com/BTL/?p=16345&tag=nl.e019

see “Smart (Enough) Systems” http://www.smartenoughsystems.com/ by James Taylor.

This is not about automating decisions made by people, it is about automating decisions that don’t need people. Dig deeper, and this is about Business Rules. In situations where all responses to a question can be defined depending on data about the situation, having people pick an answer is a waste. Biggest example? Credit Checks and your Credit Score, and ‘deciding’ to approve a request for credit. This is being done thousands/millions/whatever times per hour/day, and there not enough people available to do this.

Why do you think IBM bought iLog? Advanced companies already do this. Insurance underwriting is another big domain.

And this is never going to be about Artificial Intelligence. Smarter systems are made of the same stuff as ‘dumb’ systems, they just know more, enough to make a decision based on facts. If the facts aren’t available, the system is not going to ‘think’ or ‘reason’ its way to a decision, its just going to ask for the facts, please.

AS-IS versus TO-BE

2009-04-14T14:24:00.002-04:00

Have not seen a great methodology debate (without the word 'agile') for ages. Here is one over at Modern Analyst, with my comment already added: http://bit.ly/WNLN

IT Projects Success - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester

2009-04-08T22:48:00.000-04:00

7. One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with the specialization of Principle #6 to form the strong basis for the Cascade effect covered in Principle #13. … so stay tuned.