Flowchart Your Programming

Flowcharts have been used for quite some time for visualizing and organizing business processes and making them more efficient (e.g. business process reengineering).

Now flowcharts are being used to build and link reusable programming code.

NoFlo or Flow-Based Programming (FBP) simplifies application development by using libraries of pre-written code and then dragging and dropping them into your process flows.

This leverages objected-oriented programming (OOP) and uses modules of open-source code, which are linked together to create a full program that solves a business problem.

The flowchart helps to avoid spaghetti code by providing for a more organized, modular, object-based development environment.

These flowcharts can not only be a collaborative tool where developers can build or map code, but can also be part of the systems documentation that ensures a higher-level of understanding of the total programming solution.

NoFlo raised over $100K on Kickstarter in 45 days in order to advance this project from Javascript to iOS, Android, and Python platforms as well.

To me, this programming paradigm seems to have real legs:
– A process-based model for decomposing solutions
– Simple information visualization through a common flowcharting toolset, and
– Reusable object code from programming libraries in the cloud.

I’d say YesFLo–this makes a lot of programming sense. 😉

>From Pocketbooks to Whirlybirds

>

Miche

From Inspector Gadget to Transformers–there is more than one purpose to everything and that is the type of flexibility that we need to be agile, competitive, and efficient.

Miche Bags is a new amazing example of a company that has “got it” in terms of architecting their products for re-use.

The bags work in 3 easy steps:

1) Consumers pick a bag base–big or small.

2) Then they choose the shell (design) on the outside that they like–and this can be changed out as often as desired.

3) Finally, there are plenty of accessories–organizers and straps to select from.

Viola, your own bag creation; tire of it–and choose something else and simply swap it out.

According to CNBC, the idea for the changeable bags came when to the owner when she spilled something on one of her bags and wished that she could just change it out.

Sure, sometimes, it’s nice to have a whole new product–take my old smelly sneakers for an example–those have got to go! 🙂

But at other times, it can just make more economical and environmental sense to just freshen up a product with a change or new look.

Cell phones and smartphones seemed to have gotten that idea in their changeable “skins” that let people snap on and off different colors, textures, and materials.

Another example is Crocs (shoes) that accessorize with Jibbitz or colorful charms that snap into the holes on the shoes–these range from sports team to Disney characters, flowers, flags, and more.

Of course, there’s lots of other, more familiar examples–reversible belts and coats and removable comforter covers just to name a few.

In a dynamic and faced-paced world, where at the same time resources are more and more constrained, the ability to change out components and at the same time reuse basic elements is what is needed more than ever.

It’s great to have the versatility to personalize and accessorize skins, but it’s even better and more powerful to be able to change out components–like expanding the memory on our computers.

Like Inspector Gadget, you never know when a cap that changes to a “whirlybird propeller” that flies you out of harm’s way will come in handy!

>Civic Commons-A Lesson In Sharing

>

Love this concept on Civic Commons that was presented at the Gov 2.0 Summit (2010) and is now becoming a reality.

Presented by Bryan Sivak the CTO for DC–Civic Commons is about governments collaborating and building technology once and reusing multiple times, rather than reinventing the wheel over and over again–a critical enterprise architecture principle.

Governments have similar needs and can share common solutions–products and projects–for these.

A number of successful examples:

1) DC and San Francisco building Open 311 (which I wrote about in a prior blog).
2) Minnesota building a $50 Million Unemployment Insurance System and then sharing it with Iowa who implemented it at less than 1/2 that.

Some initial products that have been committed:

1) White House IT Federal Dashboard
2) Track DC (Operational Dashboard)
3) San Francisco Master Address Database Geocoder
4) New York Senate’s Open Legislation Application

And more will be coming…all of which can be used and improved upon.

It is great to see so many state governments collaborating–across the Nation–from Seattle to LA, Boston, San Francisco, NY, and Chicago. Moreover, they are coordinating with the Federal Government, as well as with supporting organizations, such as OpenPlans, Code For America, O’Reilly Media, and more that are helping with coordination, facilitation, and support.

This is another great step in breaking down the silos that separate us and becoming more efficient in working together and learning to share what can benefit many.

>SOA Liberates Productivity

>

Harvard Business Review (HBR), June 2008, has a wonderful article (by Ric Merrifield, Jack Calhoun, and Dennis Stevens) on how SOA is “the next revolution in productivity.”

SOA defined:

“It is becoming possible to design many business activities as Lego-like software components that can be easily put together and taken apart…service-oriented architecture [is] a relatively new way of designing and deploying the software that supports a business activity.”

With SOA, business activities can be accessed via the Internet through web services. Rather than build proprietary, redundant business services, our organizations can re-use standardized services, developed internally or outsourced, as components that plug and play into our enterprise.

“Virtually all large companies suffer from an enormous duplication of activities; they continue to create and perform hundreds of non-core tasks that would ideally be outsourced; and they are spending exorbitant amounts on IT projects in order to support redundant and nonstrategic operations and to update core processes.”

How does this differ from other quality improvement initiatives?

Prior quality improvement efforts like Total Quality Management (TQM) and Six Sigma have focused on reducing waste and defects and eliminating unnecessary tasks and integrating disparate ones.

“For the most part, however, reengineering has involved recasting processes and the information systems that support them in a proprietary, rather than a standardized, form—that is, customized for individual organizations. Such designs make it difficult and expensive for business to share, consolidate, and change processes.”

Now with the Internet and web services, we can access standardized services that can be shared and re-used throughout disparate business units in the same enterprise and across organizations globally.

The result is business units and organizations that can simply plug and play to make use of needed services, eliminating proprietary processes and redundant systems and enabling outsourcing of noncore mission functions and activities and easier upgrades to new superior services as they come online.

What are some of the issues holding SOA back?

Firstly, many people do not truly understand SOA, what it is, what benefits are possible, and what the challenges are to doing it right.

Second, SOA is viewed by many executives as yet another hype or bubble that will cost the enterprise lots of money, but fail to provide the promised return. So, they are wading into SOA only enough to “deploy it in a limited fashion,” but without first rethinking the design of their business.” However, to really reap the benefits of SOA, organizations need to transform from “collections of proprietary operations into a collection of standard plug-and-play activities,” and this requires redesigning not only IT systems, but operations.

In designing SOA-based processes, the unit of analysis and reengineering is no longer the task (as in Frederick Taylor time and motion studies of the late nineteenth century) or the department, or even the division. “In the age of the Internet and SOA, the unit of analysis is not a company’s way of conducting its operations at all; it is the primary purpose or desired outcome of each activity no matter how that activity is accomplished.”

Where are we today with SOA implementation?

“Unfortunately, few companies are using SOA to create more productive and focused organizations or to slash costs by purging duplicative operations and technologies. They are not revisiting the fundamental design of their operations.”

To overcome the obstacles in reaching SOA enabled organizations, we need a strong dose of enterprise architecture to identify and decompose our performance outcomes we are driving toward, the business processes to achieve these, the information required to perform these, and the systems that can serve them up.

According to HBR, our business model activities can be categorized into the following for SOA implementation:

  • Primary (I would call this core mission)—those that should be kept in-house and are “top priority of programs to improve operations and technology” (i.e. through business process improvement, reengineering, and the introduction of new technology).
  • Shared—those that “can be shared with other divisions” (i.e. through common solutions).
  • Shifted—those that “can be transferred to customers, suppliers, or operational specialists” (i.e. outsourced).
  • Automated—those that can be “automated so they can be turned into web services.”

All but the primary activities are ripe for SOA-based enhancements. And according to HBR, only about 20% of activities are primary, so that leaves plenty of room for a SOA plug-and-play.

The idea is to cease defining our noncore mission processes and activities as proprietary, requiring elaborate and expensive customized solutions for these. Instead, we should use standardized “swapped, bought, or sold” services. Then, we can truly focus our business process reengineering and IT investments on our organization’s core mission activities—working to to differentiate ourselves and develop unsurpassed competitive advantage.

>Occam’s Razor and Enterprise Architecture

>

“Occam’s razor (sometimes spelled Ockham’s razor) is a principle attributed to the 14th-century English logician and Franciscan friar William of Ockham…The principle is often expressed in Latin as the lex parsimoniae (‘law of parsimony’ or ‘law of succinctness’)..This is often paraphrased as ‘All other things being equal, the simplest solution is the best.’… it is more often taken today as a heuristic maxim (rule of thumb) that advises economy, parsimony, or simplicity.’” (Wikipedia)

In Occam’s razor, “razor refers to the act of shaving away unnecessary assumptions to get to the simplest explanation.”

Thomas Aquinas made a similar argument in the 13th century: “If a thing can be done adequately by means of one, it is superfluous to do it by means of several; for we observe that nature does not employ two instruments where one suffices.” (Pegis, A. C., translator (1945). Basic Writings of St. Thomas Aquinas. New York: Random House, 129.)

The principle of Occam’s razor is very applicable to enterprise architecture—how?

Occams razor is a call for simplicity, and this principle is a foundation for enterprise architecture in terms of consolidation, integration, and cost efficiency and takes specific form in terms of:

  • Systems interoperability and component re-use
  • Technology standardization and simplification

Paul O’Neill, the former Secretary of the Treasury was a true advocate of Occams razor and frequently asked “if not one, why not one?”

“The philosopher of science Elliott Sober once argued along the same lines as Popper, tying simplicity with ‘informativeness’: The simplest theory is the more informative one, in the sense that less information is required in order to answer one’s questions.” (Wikipedia)

In this sense, Occam’s razor is a validation for User-centric Enterprise Architecture, which seeks to make information simpler, easier to understand, and generally more valuable and actionable to the end-user to enhance decision making. Moreover, Occam’s razor is also evident in User-centric EA application of principles of communication and design like simplifying complex information and maximizing use of information visualization in order to more effectively communication EA information.

Occams razor makes clear the need to transform from traditional EA’s development of “artifacts” that are often difficult for the user to understand and apply and instead develop more useful and usable information products and governance services.

>Simplification and Enterprise Architecture

>

Enterprise architecture seeks to simplify organizational complexity through both business processes reengineering and technology enablement. Technology itself is simplified through standardization, consolidation, interoperability, integration, modernization, and component reuse.

Harvard Business Review, December 2007, reports on simplifying the enterprise.

Large organizations are by nature complex, but over the years circumstances have conspired to add layer upon layer of complexity to how businesses are structured and managed. Well-intentioned responses to new business challenges—globalization, emerging technologies, and regulations…–have left us with companies that are increasingly ungovernable, unwieldy, and underperforming. In many more energy is devoted to navigating the labyrinth than to achieving results.”

Having worked for a few large organizations myself, I can “feel the pain.” Getting up to 8 levels of signature approval on routine management matters is just one such pain point.

What causes complexity?

Complexity is the cumulative byproduct or organizational changes, big and small that over the years weave complications (often invisibly) into the ways that work is done.

What is sort of comical here is that the many change management and quality processes that are put in place or attempted may actually do more harm than good, by making changes at the fringes—rather than true simplification and process reengineering at the core of the enterprise.

Here is a checklist for cutting complexity out of your organization:

  • “Make simplification a goal, not a virtue—include simplicity…[in] the organization’s strategy; set targets for reducing complexity; create performance incentives that reward simplicity.
  • Simplify organizational structure—reduce levels and layers…consolidate similar functions.
  • Prune and simplify products and services—employ product portfolio strategy; eliminate, phase out, or sell low-value products; counter feature creep.
  • Discipline business and governance processes—create well-defined decision structures (councils and committees); streamline operating processes (planning, budgeting, and so on).
  • Simplify personal patterns—counter communication overload; manage meeting time; facilitate collaboration across organizational boundaries.”

Leading enterprise architecture and IT governance for a number of enterprises has shown me that these initiatives must be focused on the end-user and on simplifying process and improving results, rather than creating more unnecessary complexity. The chief architect needs to carefully balance the need for meaningful planning, helpful reviews, and solid documentation and an information repository with simplifying, streamlining, consolidating, reengineering, and facilitating an agile, nimble, and innovative culture.