Showing posts with label Decomposition. Show all posts
Showing posts with label Decomposition. Show all posts

May 21, 2019

Nightmares All Night

Been watching the HBO miniseries on the Chernobyl nuclear reactor disaster. 

HBO has done an excellent job with showing what happened. 

Maybe too good...I was up with nightmares all night. 

Last night's episode 3 showed in gory detail the initial causalities from the facility and first responders suffering with acute radiation syndrome, and was completely horrifying. 

In the end, the people were in unimaginable pain and were left as mounds of decomposing flesh from the cellular degradation rather than recognizable human beings.  

(The photo here was just a precursor to that end state.)

The ultimate death toll has been estimated at between 10,000 and more than 100,000. 

The effects of the the radiation was described in the show as like trillions of bullets penetrating everything it comes in contact with for the next 50,000 years.

So far we've had Chernobyl (1986) and Fukushima (2012)...OMG, let's hope and pray that we don't have any others, because this was truly looking at hell on earth. ;-)

(Source Photo: Official Trailer here)
Share/Save/Bookmark

May 13, 2011

Who's On First

I have a new article in Public CIO Magazine (April/May 2011) on the topic of Accountability In Project Management:

We've all be to "those" kinds of meeting. You know the ones I'm talking about: The cast of characters has swelled to standing-room only and you're beginning to wonder if maybe there's a breakfast buffet in the back of the room.

It seems to me that not only are there more people than ever at todays meetings, but meetings are also more frequent and taking up significantly more hours of the day.

I'm beginning to wonder whether all these meeting are helping us get more work done, or perhaps helping us avoid confronting the fact that in many ways we're stymied in our efforts.

Read the rest of the article at
Government Technology.


Share/Save/Bookmark

April 16, 2010

Breaking Down Organizational Bottlenecks

Improving organizational performance is often grounded in identifying bottlenecks (constraints) and fixing them, so that the firm runs better, faster, cheaper than before and at an advantage to it’s competitors.

Enterprise architecture helps us to locate the bottlenecks through an understanding of our business processes, information flows, and systems and then facilitates our reengineering these though business process improvement and the introduction of new technologies.

Harvard Business School (HBS) put out a working paper in February 2010 called “The Strategic Use of Architectural Knowledge by Entrepreneurial firms,” by Carliss Baldwin that describes how “an entrepreneurial firm can use architectural knowledge to unseat a larger incumbent.”

The premise is that knowledge is a firm’s most critical resource, “including knowledge about how to assemble resources to pursue an opportunity.”

We can architecturally disassemble and assemble our resources and processes whereby we—“isolate the bottlenecks” and then “alleviate the bottlenecks.”

This process is grounded in modularity theory, where we use architectural knowledge to modularize (or breakdown) a complex system into its functional components as well as address how these components are related (through their interfaces).

Once we decompose the firms business, data, and systems into its modular components, we can then “remodularize” (or assemble) them into strategically more effective systems for doing business.

Moreover, the paper suggests that the firm “insources bottleneck components and outsources non-bottleneck components,” so as to focus resources (and innovation) on the trouble spots—the areas that are potentially a source of competitive advantage.

Fixing bottlenecks can produce valuable differentiators for a company that we would not want shared with those outside the organization and made available to competitors.

In my opinion, bottleneck functions can also be outsourced, whereby we decide to “let the experts handle it,” when the functions are not strategic in nature. For example, many companies outsource things like payroll and basic call center functions, and it enable the organization to focus its energy and efforts on its core mission.

The notion that enterprise architecture itself is a strategic differentiator for organizations that know how to wield the architecture knowledge is critically important. Through decomposition and assembly of processes and enabling technologies, we can create stronger organizations that not only reduce bottlenecks, but also drive improved decision-making in terms of what to invest in and how to source those investments.

While many organizations treat architecture as a compliance only mechanism and reap little to no benefits from it, those that understand EA’s strategic significance can use the knowledge gained to their organization’s competitive advantage.


Share/Save/Bookmark

September 25, 2009

Nanotechnology and Enterprise Architecture

“Nanotechnology is the engineering of functional systems at the molecular scale. In its original sense, 'nanotechnology' refers to the ability to construct items from the bottom up.” (Center for Responsible Nanotechnology)

Two examples of nanotechnology include the manufacturing of super strength polymers, and the design of computer chips at the molecular level (quantum computing). This is related to biotechnology, where technology is applied to living systems, such as recombinant DNA, biopharmaceuticals, or gene therapy.


How do we apply nanotechnology concepts to User-centric EA?
  • Integration vs. Decomposition: Traditional EA has looked at things from the top-down, where we decompose business functions into processes, information flows, and systems into services. But nanotechnology, from a process perspective, shows us that there is an alternate approach, where we integrate or build up from the bottom-up. This concept of integration can be used, for example, to connect activities into capabilities, and capabilities into competencies. These competencies are then the basis for building competitive advantage or carrying out mission execution.
  • Big is out, small is in: As we architect business processes, information sharing, and IT systems, we need to think “smaller”. Users are looking to shed the monolithic technology solutions of yesteryear for smaller, agile, and more mobile solutions today. For example, centralized cloud computing services replacing hundreds and thousands of redundant instances of individuals systems and infrastructure silos, smaller sized but larger capacity storage solutions, and ever more sleek personal digital assistants that pack in the functionality of cellphones, email, web browsing, cameras, ipods, and more.
  • Imagination and the Future State: As architects, we are concerned not only with the as-is, but also with the to-be state (many would say this is the primary reason for EA, and I would agree, although you can't establish a very effective transition plan without knowing where your coming from and going to). As we plan for the future state of things, we need to let our imagination soar. Moore’s Law, which is a view into the pace of technological change, is that the number of transistors on an integrated circuit doubles every 24 months. With the rapid pace of technological change, it is difficult for architects to truly imagine what the true possibilities are 3-5 years out--but that can't stop of from trying based on analysis, trends, forecasts, emerging technologies, competitive assessments, and best practice research.

The field of information technology, like that of nanotechnology and biotechnology is not only evolving, but is moving so quickly as to seem almost revolutionary at times. So in enterprise architecture, we need to use lots of imagination in thinking about the future and target state. Additionally, we need to think not only in terms of traditional architecture decomposition (a top-down view), but also integration (a bottom-up view) of the organization, its processes, information shares, and technologies. And finally, we need to constantly remain nimble and agile in the globalized, competitive marketplace where change is a constant.


Share/Save/Bookmark

May 16, 2008

Classification Schema and Enterprise Architecture

User-centric Enterprise architecture captures organizational information, analyzes it, and classifies it, and serves it up to the end user in useful and usable ways to enhance decision-making.

I came across a helpful article in DM Review, May 2008, called “Ontology and Taxonomy” that clarified the classification schemas used in EA.

First of all what the heck is a classification schema?

Simply put, a classification schema is a way of organizing information by putting things into categories. This helps us make sense of the information by being able to relate items to one another. For example, is an item, part of a larger supertype? Does an item has subtypes? Are items part of a common set? Is there a one to one relationship, a one to many, or a many to many? An understanding of these relationships between information helps us to understand the information and better use it for sound decision making.

Here are the two classification schema:

  1. Ontology—“includes putting things into categories and relating these categories to each other…an ontology is a model…’ontology concerns itself with the organization of knowledge’…the body of knowledge includes both class and instance.” Ontologies define relationships. In ontologies, we identify the intersection of different items with each other, so for example a man intersects with “person,” “male,” and “adult.”
  2. Taxonomy—“A taxonomy is an ontology in the form of a hierarchy.” Typically, taxonomy takes the form of a tree diagram, with parent (class) and child relationships. Taxonomies are decompositions. “For example, a parent may be automobiles and the children may be trucks, SUVS, sedans, compacts, and so on. Then the children for trucks may be pick-ups, vans, refrigerated, etc.

One of the problems with taxonomies is that you cannot easily define everything neatly into categories and subcategories, such as in cataloging a body of knowledge. For example, in the Dewey decimal system, “Where do you put a book about the history of mathematics in the Islamic world? History? Mathematics? Religion? That points out the problem with most taxonomies. Most of our knowledge is not hierarchical.”

The limitation of taxonomies is why we need to use more sophisticated ontologies such as business, data, and system models in enterprise architecture to understand the complexity of the relationship between business processes, information required to perform those, and the systems that serve those up.


Share/Save/Bookmark

February 22, 2008

Business Process Management and Enterprise Architecture

Modeling business processes, information flows, and the systems that serve up that information is core to developing enterprise architecture

DM Review Magazine, February 2008 reports that Business Process Management (BPM) changes the game for business performance through process innovation, creating a process-managed enterprise that is able to respond to changing market, customer, and regulatory demands faster than its competitors.”

How does BPM enable enterprise efficiency?

“It acts as the glue that ties together and optimizes existing attempts at employee collaboration, workflow, and integration. It drives efforts in quality improvement, cost reductions, efficiencies, and bottom-line revenue growth.”

BPM drives “the ability to design, manage, and optimize critical business processes.”

Essentially the decomposition of functions into processes, tasks, and activities along with linkages to the information required to perform those and the systems that provide the information enable the enterprise architect to identify gaps, redundancies, inefficiencies, and opportunities for business process improvement, reengineering, and the introduction of new technologies.

Business, data, and systems models are an important tool for architects to integrate and streamline operations.

How effective is BPM?

The Aberdeen Group reports “more than 50% of companies surveyed were expected to turn to BPM in 2007 to get the process right at the line-of-business level without having to throw out their expensive enterprise resource planning (ERP) or custom back-end applications investments.”

Similarly, Gartner reports that “organizations deploying BPM initiatives have seen more than 90 percent success rates on those projects.”

What are some critical success factors in BPM?

  1. Usability—“intuitive and flexible user interfaces.”
  2. Process analysis—“knowledge management, analytics, reporting, and integration functionality.”
  3. Collaborative—“portals, attached discussion threads, document management capabilities, and configurable task views.”
  4. Self-optimization—“ability to ‘self-optimize’ the process.”
  5. Focus on high-value areas first—“initial BPM project should include areas of medium-to-high business value combined with low process complexity…choose processes or business areas that have high visibility.”

From a User-centric EA perspective, modeling business, data, and systems is a key element at the segment and solutions architectures. These models enable the development of business requirements, information flows, and technology needs that help determine the ultimate solution design and line of business projects. These in turn feed the enterprise architecture target architecture and transition plan. So the food chain often starts with core modeling initiatives.


Share/Save/Bookmark