Functional Architecture Principles

Functional Architecture as a discipline has been brewing for a few years now. I have been a “functional architect” for a software application, and have also been involved in functional architecture review of enterprise software programs. I won’t claim to know what functional architecture means in any universal sense, but having done this work, and been in this role, I can describe some functional architecture principles that I know are helpful to making software more valuable in an enterprise context.

Functional architecture has several aspects.  Read more ›

Posted in IT Strategy Tagged with: , , ,

Five Lessons Learned From Consulting Engagements

In a recent post about consulting engagements, I talked about some of the challenges with consulting organizations and their standard practices. I thought maybe some might benefit from some insight.  These are some specific suggestions for handling these kinds of challenges.

1) Consulting firms have “relationship” managers or “engagement” managers – these are people whose job on the project it is to ensure the customer is satisfied. It is their corporate mission to ensure that your company spends more money with them. They are sales people. They come to your project meetings, with a stated purpose of making sure that the project is smooth and successful. Their “other” purpose is to develop a deeper network in your organization, and to “discover” other opportunities for their firm to “help”. While they may have expertise, industry knowledge, and skills that help your organization, it is worthwhile to question whether they should be billable on your engagement. Read more ›

Posted in Culture, Leadership Tagged with: , , ,

Consulting Engagements

My current role is interesting. I am an internal IT consultant in a large financial corporation. As an internal consultant I am free to work on as many projects as I can juggle. My billing is only explicit when I work on capital projects. I spend more time talking than “working”. Most of my working is writing. Yes, making PowerPoint decks is considered writing.

Over the past year, most of my own internal consulting engagements have involved some coaching. Coaching leaders on the business side of our organization through projects with IT entanglement. Coaching IT leaders through adoption of new technology or practice patterns. Coaching project leads into positions of transparency and truth telling. Coaching different kinds of leaders through developing guiding principles that make all the little decisions easier. Interestingly enough, the coaching is not really what I was engaged to do. It simply flowed from my understanding of the needs of individuals in the project context to be successful.

Recently, I have been working with a number of external consultants. Teams, actually. Teams of consultants from big 5 firms. I have been attached to the same project as they have, and to them, I am a SME and a network adapter. I share my knowledge of organizational practice and my interpersonal network with them, so that they can get their deliverables accomplished.

What I often struggle with is the shallow depth of their analysis. Their engagements are short, usually in increments of 6 week intervals. They spend a lot of time collecting data but not really producing information. They have methodologies that I suppose would be effective if the data/information they were fed were appropriately scrubbed and semantically understood. Read more ›

Posted in IT Strategy Tagged with: ,

A taxonomy of software types

Generally, software falls into three classes; Apps, Tools, and Infrastructure.

The Breakdown

Apps – or applications as they were formerly known – are software built to help a user do some valuable activity, like check a bank balance or edit digital images. While the end user must learn how to use it, an app is useful without further development. Some apps are configurable, so can work differently for different users or organizations, but they are still focused on solving problems or delivering value related to some specific functional domain.

Tools – are software that are more general purpose, but with a specific flavor – that they are designed so that users of these can use them to “fashion” applications for themselves or other groups of end users. Tools express their own user experience, but are not always immediately valuable without some “fashioning”. Tools can range from Microsoft Excel to Sharepoint to web content management systems like WordPress, to giant ERP systems like SAP or Peoplesoft. Many business intelligence product fall into this category.

Infrastructure – are software that really has no end user experience. They are designed completely as a foundation for other software to be built upon. This would include any software whose primary interaction mode is through API (application programming interfaces) or CLI (command line interface) patterns. Products like databases, middleware, application servers, application frameworks all fall into this category.

So why is it so confusing to people? Because technology has its own functional domains. These classes are not mutually exclusive, in that for one user it is an application and another it is a tool. With add-ons, extensions, or plug-ins it becomes even more confusing, as these constructs blur the lines between tools and applications even further. Plug-ins for a tool, may be applications focused on one functional domain. Read more ›

Posted in IT Strategy Tagged with: , ,

Feats Instead of Processes

In my last post on Software Capabilities and Feats I said that feats are better [to model in a software capability] than processes, because processes are merely organized, consistent, managed ways to accomplish the feat.

A process is one way to accomplish a feat. The feat is the result you want.

Process is constrained by capabilities. So when I am modeling new capabilities, I should not be constrained by existing capabilities. When I introduce the new capability into the wild, the process will need to “re-form” around the new capability.

A process has steps. If we build software capabilities to support a process, we treat the steps of the process like “feats”. I can model a capability to make that step faster or more effective. That assumes that the step is necessary. In order to decide whether a process step is “necessary” I need to understand how it contributes to the valuable result. I need to understand why I do the step. Read more ›

Posted in Requirements Tagged with: , ,

Software Capabilities and Feats

In some recent conversations, I find that it is hard to explain the notion of a capability. People want to talk in terms of software features or project requirements.

Software capabilities define value in the following ways:

  • enabling the user to accomplish a “feat” in less time than they otherwise would.
  • enabling the user to accomplish a “feat” at a greater scale than they otherwise would.
  • enabling the user (or a group of users) to accomplish a “feat” more effectively than that they otherwise would.
  • enabling the user to accomplish a “feat” that he could otherwise not accomplish at all.
  • enabling the user to accomplish a “feat” better than he otherwise could.
  • enabling the user to focus on “feats” that require decisions, rather than repetitive steps.

Every other benefit of software can be composed from these.

To define value, a software capability must contemplate (model) the “feat” that the user wants to accomplish. Read more ›

Posted in Requirements Tagged with: , ,

The Other Side of Product Investment

If you are a project manager that does software projects, you deal with the “top side” of product investment all the time. Whether your teams are running agile like scrum or kanban, or whether they are running a phase-gated cycle (waterfall), you are focused on the decisions about organizing the investment into packages for release or deployment. You are running the factory which takes requirements in one end and (hopefully) spits working features out the other. You are working with the analysts or product people to ensure that there are enough requirements, stories, or ideas “ready to start” to keep the team occupied.

But what about the other side of product investment? We often talk about return on investment or ROI, but most organizations only use an ROI project to justify the investment. Some will go as far as to attempt to measure “hard” ROI numbers, but frankly even that is missing half the boat because it is hard to measure the impact of software capability on your organizations top line or bottom line. Without a body count, the best we can do is to infer the correlation of software capabilities to a movement in profitability and assume that the relationship is causal. When it comes to softer benefits like risk reduction, customer satisfaction, or employee retention, there is no reasonable way to measure “hard” ROI dollars. Read more ›

Posted in Software Team Tagged with: , , , ,

The Perfect Product Road Map

At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:

Capabilities and Adoption.

in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials. Read more ›

Posted in IT Strategy, Software Team

System Replacement Assumptions

I am in the middle of my umpteenth system replacement project.  There are some universal assumptions that are endemic to the user community in every system replacement project.  They are born of hope and frustration.  They are almost universal.

1) The new system will do everything the old one does, only better.
2) The new system will support all of my existing processes and procedures without significant change.
3) The new system will be faster that the old system.
4) The new system will have better data quality than the old system.
5) The new system will address ALL of the shortcomings of the old system.

If you have ever done one of these projects, you know.  They are assumptions that you must actively work against.  They require a constant stream of communication to dispel. I offer you my rationale for why they are never, ever, true. Read more ›

Posted in IT Strategy, Leadership Tagged with: , , , , ,

Decision Let-down

Leadership must recognize that momentum is lost when decisions are anti-climactic.  As a leader, it is tempting to focus on the decisions as your primary responsibility – but that is only half of the problem.  When decisions are not incisive, are not positive, result in no obvious actions or next steps – our responsibility is to keep the team from getting demotivated, confused, or de-focused.   Read more ›

Posted in IT Strategy, Leadership Tagged with: , , ,