Tag Archive | Business

Posting for July 15, 2013


Start with this posting on Software Product Lines.

More On Software Product Lines

Consider the pairings below and how their members relate.

  • information : binary counter
  • binary counter : (switch, register, flag, data)
  • (switch, register, flag, data) : code
  • code : function : routine : application

When we talk about software product lines, we are talking about information and ultimately its application.

Small yes/no decisions.  Larger logical sequences.  Historical data.  Hardware and software components plus that data.  Information systems in support of business.  Business products and services.

Technology can enable these products and services.  Manual systems also, can enable business process and information systems.

Organizations get to a state of maturity around information and the portfolio of application, and begin to ask questions about their efficiency to deliver on these.

Let’s continue to consider pairings.

  • application : service : components & data
  • components & data: core assets
  • core assets : business products & services : technology products & services : enterprise architecture
  • governance of (core assets : business products & services : technology products & services : enterprise architecture)

The business case for software product lines explores these questions:

  • In general, is it worthwhile to mature – to improve – and if so, what is the value and the risk of doing so?
  • Is there specific value in evaluating how we manage components & data?  What is that value?
  • What industry models might aid us to think through these questions?  How do we leverage them?

Is there business benefit in thinking of components & data as Core Assets?  What do we mean by that and what are the implications?

© Michael C. Simonelli, onthegocio.com, 2013

Intro to Software Product Lines


This is the first in a series of postings on the topic of Software Product Lines

Consider that software engineers are potentially the worst people to decide what software to engineer.  Their view is typically myopic, founded in satisfying the immediate demand, usually project-based, executed in silos with limited insight into what Teams B and C might be doing.

The ability to look across the teams, across all the Ask on the table, and to decide if there are efficiencies to be gained in more creative and rationalized delivery, is an ability that Business would do well to evolve.  Many of the competencies comprising this ability are both technical and non-technical in nature.  We will explore these over upcoming posts.

A simple non-tech example to illustrate some fundamentals

A slow-food joint makes burgers.  Order a single, a double, or a triple, and the folks in the back will fulfill the order.  Think of these as small kitchen projects.  They start from scratch for each order – remove the ingredients from various refrigerator units, get the spices down from the shelves, add quantities by eye, mix by hand, shape to arbitrary design, throw the burger on the grill, bun ’em up, apply condiments, side-plate the fries, clean-up and put away all.  A long line of preparers queues up to do the very same as the kitchen is small, and the culture is such that you wait your turn for the limited space and resource, do not work concurrently or in tandem in the kitchen across orders – even for those coming from a single table! –  and you don’t breathe a word to anybody about the contents of your order.  Customers, at first delighted knowing that their food is fresh and made to order, soon become disenchanted with the long waits, the staggered arrival of food, the lack of uniformity in the product, and the declining mood of the eatery’s workers.

Sounds pretty ridiculous, doesn’t it?  And I bet it’s relatively easy to name at least 2 or 3 pain-points in the governing policy, process and the culture’s behavior, that if addressed, would make the establishment more efficient, customer-friendly, and profitable.

A simple tech example to extend the point

  • Business Unit 1 wants to create new product offering for the Customer (or client, or student, or insured, or employee, or patient, or sovereignty, or channel, or some other entity more appropriate for your work and industry),
  • Business Unit 2 wants to enhance an existing product offering for the Customer.
  • Business Unit 3 needs to implement regulatory mandates affecting the Customer.

You kick off 3 separate projects.  You size and estimate, staff, plan and schedule each project, and run each in relative isolation of the other.

It is not long before you begin to resemble the slow-food eatery.

The three project teams begin to work on Customer, meaning source software and data assets, as well as the physical assets where those are instantiated, to fulfill their respective delivery obligations.  Team 2 overwrites the work of Team 1.  Team 3’s business logic is contrary to the functionality that Team 1 desires.  Team’s begin to rig local instances of databases to avoid the queue that’s building there around the architecture and DBA function.  Test data management teams begin to back up, processing 3 separate requests.  Integrated testing environments are booked, delaying Projects 1 and 2, since the Regulatory nature of Project 3 trumps, allowing them sole residence there until further notice.  Project 3 though is somewhat dependent on Project 2’s enhancement.

Business Unit 1 begins to adjust their revenue projections based on delayed entry into the market.  Even the CEO is a bit concerned as she foresees impact to brand.  Regulatory is starting to talk about major fines due to lack of compliance.  In a few months customers will begin to wonder if the grass is greener on your competitor’s side of the valley.

And the music goes round and round – and it comes out . . .

Here – the Uber Effort

In the spirit of this writing, I will reuse an earlier paragraph:

Sounds pretty ridiculous, doesn’t it?  And I bet it’s relatively easy to name at least 2 or 3 pain-points in the governing policy, process and the culture’s behavior, that if addressed, would make the establishment more efficient, customer-friendly, and profitable.

Here’s my list of observed pain points gleaned from the example above.  For starters, the Business would do well to have:

  1. A holistic view of the demand from the business units.
  2. An architecturally integrated view of the work that needs to be performed across the 3 projects, especially since they all 3 are touching on a common set of Core Assets (more on this in future posts).  Consider that what was once 3 distinct and dis-integrated Analysis & Design phases, one for each of the projects, will collapse to One, with each effort inheriting a grander design for the benefit of all.
  3. An integrated Production Plan and schedule for delivery that creates efficiencies in all 3 efforts (appreciate that the line between the 3 projects will blur into something else of greater benefit).  This will create efficiencies in downstream practices for Test Data Management, Environments Provisioning, the allocation of third-party and vendor resources, and much more.
  4. A clear attributing of dependencies and priorities to serve as decision-making guidelines.

We will continue to explore these topics in an upcoming series of posts.  Next week, more on the Business Case for software product line practices, and Core Assets.

This art is paid for and used under Non-Exclusive license agreement with Condé Nast.
Cartoonist: Bruce Eric Kaplan, The New Yorker Collection
Issue Publication Date 01/11/1999
The Cartoon Bank TCB-40677, Image ID: 8298

© Michael C. Simonelli, onthegocio.com, 2013

When do we actually work?

“Today’s meeting will be endless, with a half-hour break for lunch.”

Have you experienced the endless meeting?  Maybe it’s not just one meeting.  Instead,  it’s an endless parade of meetings, starts in January and ends in December – starts Monday ends Friday – 8AM to 6PM – back to back to back.

Have we become a working culture where the meeting is the work?  Is the meeting the only and best tool we have?

Consider that a meeting is time and venue for people to assemble, to check status, discuss issues, contemplate futures, make decisions, create new concepts – essentially plan, check, control, report, and innovate.  Do we know how to use meetings effectively to meet the various results listed here?  Does your organization offer guides on how to conduct these different meeting flavors?

Poll your organization, asking them if the meetings they conduct and attend, are effective and efficient.  If they are not, then when does the work actually get done?

Is it typical for your meetings to start and end 5 to 10 minutes late? Everybody have a conference number, and a moderator code?  Should they? Have these become entitlements? Do we use meeting tools like Outlook and PowerPoint effectively, or perhaps even to our detriment?  Does your team rely on digital tools, more than or exclusive of analog tools?  Are meeting work-products, like agenda, minutes, and a decision log commonplace, and well-managed?  What other sort of work products do you have upon exit from a meet?

Do we actually need meetings?

Is the need to meet (and email and other forms of meeting) a byproduct of how we design our work environments and distribute our team members?   Consider that co-location, open floor plans, and specific design of collaboration spaces, contributes to greater productivity in various ways.

This art is paid for and used under Non-Exclusive license agreement with Condé Nast.
Cartoonist: David Sipress, The New Yorker Collection
The Cartoon Bank TCB-135093, Image ID: 21865

© Michael C. Simonelli, onthegocio.com, 2013

Big Data Offers No Value

“I’ll pause for a moment so you can let this information sink in.”

From data, to information, to analytic.  We pause for a moment, to let it sink in, to discern the shapes, to see the possibilities, to find the opportunities, to assess the risks.

Big data, in and of itself, offers no value.  The value is in big data analytics:  algorithms to enable us to see the sublime, the hidden, the multivariate substrate, the fractal, the organic, the qualitative, the subliminal, the possible, the seemingly impossible.

The output at times is modern, impressionistic art, Jackson Pollock socialgraphs that resemble the endless spirals and birthed nodes, typical of emerging universes.

We discern woven patterns, sense cultural sentiment, see the future, learn from the past, and fine-tune the now.  We do it for the cause, the brand, the shareholders, the storyline, for reasons altruistic.

We seek to better correlate the elements of the mundane, while also gleaning the game changers.

It’s not just comparing apples to apples any longer; it’s apples to oranges to kumquats to rhubarb, connecting a to b to z, to green to yellow, to 2013 retail sales, to last month’s insurance claims for fractures, to bond ratings for all sovereign entities for the last 50 years,  to every Like of every Tweener, to the tweets of every Boomer, and back again to apples.

Occasionally there’s that rare “aha!”  to compel and propel us to new markets and channels, to extraordinary shifts in the accepted point of view, to brave new worlds.

Let it sink in so that we can do something meaningful: market or sell or improve something, create a better We, the next-gen They, an Us greater than the sum of the constituents.

Sometimes we do it purely for profit.

This capability requires that we plan, manage and control, the infrastructure and the analytics lifecycle: platform provisioning, data acquisition, sharing, making it easy to shop and access the mart, assuring informational integrity – semantic, syntax, and lineage – aging, sunsetting, and disposal.

The information will sink in when the organization feels confident about data quality (impeccable and timely), and platform availability (ubiquitous, persistent, and hardened), and accepts the information as an operational given, and not an anomalous and premium deliverable from Information Technology.

Here’s to the next generation of those who will solve world hunger, cure major diseases,  win elections, safeguard national security, or decide the next flavor-themes for Lunchables, using big data analytics.

This art is paid for and used under Non-Exclusive license agreement with Condé Nast.
Cartoonist: Gahan Wilson, The New Yorker Collection
The Cartoon Bank TCB-133982

© Michael C. Simonelli, onthegocio.com, 2013


Don’t Align IT to Business Goals

Consider that you do not want to align IT goals to your business goals.

Just as you do not want to improve the effectiveness of communications between silos. Wouldn’t you rather break down the silos and replace those with a single, cohesive unit?

My arm doesn’t align to the trunk of my body; it is a natural and inevitable outgrowth. Similarly, you want IT to grow out of the business, eliminating totally the need for alignment.

Let’s take a look at a performance framework known as GOSPA, an acronym for: Goals, Objectives, Strategy, Plans, and Action.  It is like Hoshin Planning, a straightforward approach for cascading from strategic to tactic.

Simply put: Goals drive Objectives drive Strategy drive Plans drive Action.

There are those who advocate aligning IT to the business goals. If we take this literally, IT and business would have the same objectives, strategies, plans, and activities.  While this might sound correct to some, consider that this is not a desirable outcome.

The Business has its own very specific goals and objectives, inspired by market, regulatory, sense of mission, community, and other factors.  Information is critical to support business processes that support these aspirations.

The business identifies and seeks to act on strategies for its information.  One strategy, a commonplace one, is to leverage Technology in support of information usage.  The other is the strategic decision to invest in and support an internal IT organization, and contract with it to provision products and services to meet very specific Objectives.

This is where Alignment needs to occur, where IT Goals intersect with Business Strategy.

IT Goals, the top of a new GOSPA foodchain, begin with Business Strategy.  Perhaps that goal is to be the premiere provider of solutions, products, and services, to enable the business to meet its strategies, objectives, and goals.  Or to serve as prime contractor on behalf of the business, for 3rd party technology providers,  IT then has its very own objectives, strategies, plans, and actions, to meet their very specific goals.

Semantics?  Perhaps.  But consider that in this model there is no alignment in the way that it is often used in this context, of IT meeting the Business.  There are not 2 distinct entities that need reconciliation and a meeting of the minds.  Instead, consider a single, organic movement, born of the Business, a natural and inevitable outgrowth, like my arm on the trunk of my body.

Intersection of Strategy and Goals

© Michael C. Simonelli, onthegocio.com, 2013