Showing posts with label Models. Show all posts
Showing posts with label Models. Show all posts

January 19, 2022

Models on The Shelf

This was interesting display of female models. 

You can pick the cards with the models you are interested in. 

Seems a little obsolete in the time of the Internet when it could all be online.

Also, seems more than a little degrading to line them up on a shelf like any  commodity in a store. 

People are not things for peddling (or Human Trafficking!), and this seems like it sends the wrong message especially about women.  

At least if you threw in some male models here too, it wouldn't come across so grossly misogynistic. ;-)

(Credit Photo: Andy Blumenthal)


Share/Save/Bookmark

June 4, 2019

Wig and Taped Mouth

Thought this was a pretty scary mannequin. 

Aside from the disheveled hair covering her head and half her face. 

You can see that her mouth and nose is taped over with clear masking tape!

Clearly she looks like she has been abused or worse, and the image is that she can't even scream for help. 

Why anyone would advertise women's fashion in this misogynist way should be beyond all of us. 

There are a lot of crazy nuts out there.

This photo is a small reminder of what we face in terms of ugliness in this world. 

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

October 26, 2012

The Integrated Hat

Even a hat can get a A+ for integration and this one does. 

It comes as a nice straw hat with eye slots and a sunglass effect built in--just roll the front lid up and down to adjust the coverage. 

Takes a little of its strong look from Batwoman and a lot from the runway models of Fashion Week. 

I like it for its creativity and coy looks--not so much for it's functionality, I am sure. 

So Apple may have a lock-up on integration when it comes hardware and software these days, but Kate Spade has it hats-off in the fashion arena.  

(Source Photo: Andy Blumenthal)

Share/Save/Bookmark

October 10, 2009

Making Something Out of Nothing

At the Gartner Enterprise Architecture Summit this past week (October 7-9, 2009), I heard about this new math for value creation:

Nothing + Nothing = Something

At first, you sort of go, WHAT?

Then, it starts to make a lot of sense.

Seemingly nothings can be combined (for example, through mashups) to become something significant.

When you really think about it, doesn’t this really happen all the time.

INFORMATION: You can have tens or thousands of data points, but it’s not till you connect the dots that you have meaningful information or business intelligence.

PEOPLE: Similarly, you can have individuals, but it’s not until you put them together—professionally or personally—that you really get sparks flying.

Harvard Business Review, October 2009, put it this way:

Ants aren’t smart…ant colonies are…under the right conditions, groups—whether ant colonies, markets, or corporations—can be smarter than any of their members.” This is the “wisdom of crowds and swarm intelligence.”

PROCESS: We can have a workable process, but a single process alone may not produce diddly. However, when you string processes together—for example, in an assembly line—you can produce a complex product or service. Think of a car or a plane or a intricate surgical procedure.

TECHNOLOGY: I am sure you have all experienced the purchase of hardware or software technologies that in and of themselves are basically useless to the organization. It’s only when we combine them into a workable application system that we have something technologically valuable to the end-user.

Whatever, the combination, we don’t always know in advance what we are going to get when we make new connections—this is the process of ideation, innovation, and transformation.

Think of the chemist or engineer or artist that combines chemicals, building blocks elements, or colors, textures, and styles in new ways and gets something previously unimaginable or not anticipated.

In a sense, organization and personal value creation is very much about creating relationships and associations between things. And a good leader knows how to make these combinations work:

Getting people and organizations to work together productively.

Generating new ideas for innovative business products or better ways of serving the customer.

Linking people, process, and technology in ever expanding ways to execute more effectively and efficiently than ever before.

Enterprise architecture shares this principle of identifying and optimizing relationships and associations between architectural entities such as business processes, data elements, and application systems. Typically, we perform these associations in architectural models, such as business process, data, and system models. Moreover, when we combine these models, we really advance the cause by determining what our processes are/should be, what information is needed to perform these, and what are the systems that serve up this information. Models help architects to identify gaps, redundancies, inefficiencies, and opportunities between the nothings to improve the greater whole of the something.

The real enterprise architect will make the leap from just describing many of these elements to making the real connections and providing a future direction (aka a target architecture) or at least recommending some viable options for one.

Nothing + Nothing (can) = Something. This will happen when we have the following:

  • The right touch of leadership skills to encourage, motivate and facilitate value creation.
  • The allocation of talented people to the task of combining things in new ways.
  • And the special sauce—which is everyone’s commitment, creativity, and hard work to make something new and wonderful emerge.


Share/Save/Bookmark

October 23, 2008

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

May 8, 2008

Business Process Management and Enterprise Architecture

Business process management is part of enterprise architecture. Enterprise architecture is often equated with IT architecture. This is incorrect; they are not the same. IT architecture is focused on IT solutions. Enterprise architecture is broader and encompasses engineering both business and IT sides of the organization.

There are two primary ways that enterprise architecture modernizes and transforms the organization. From the technology side, you can introduce new technologies to enable mission. From the business side, you can reengineer or improve existing business processes.

“Business process management (BPM) is a method of efficiently aligning an organization with the wants and needs of clients. It is a holistic management approach that promotes business effectiveness and efficiency while striving for innovation, flexibility and integration with technology.” (Wikipedia)

Where does BPM fit in with enterprise architecture?

To answer this we can look at guidance from The Office of Management and Budget (OMB). Particularly Circular A-11 provides guidance on the submission of federal budgets; Part 7 (Planning, Budgeting, Acquisition, and Management of Capital Assets) spells out the requirement that an Exhibit 300 be completed for all major investments.

Aside from extensive questions for justifying your budget in the Exhibit 300, there are what’s commonly called the “Three Pesky Questions.” The 3rd of the three pesky questions is as follows:

  • “Does the investment support work processes that have been simplified or otherwise redesigned to reduce costs, improve effectiveness, and make maximum use of commercial, off-the-shelf technology? If not, management should reengineer business processes first, then search for alternatives, or the agency may issue a very broad statement of the requirements in a solicitation to the private sector and allow the private sector to do the reengineering in proposed solutions. Management should also improve internal process through cutting red tape, empowering employees, revising or pooling existing assets within the agency or with other agencies, redeploying resources, or offering training opportunities.”

What’s key here is the requirements that before planning to acquire capital assets, such as new IT, we first look to reengineer the underlying business processes. Only once we have addressed the BPM, do we look to enable these processes with IT.

How do we reengineer our business processes?

DM Review, 18 April 2008, reports that “BPM includes the modeling, implementation, measurement and monitoring of business processes.”

Here is the way I see it:

  • Three types of models: Business process (or activity) models are the first step, supported by data models and systems models.
  • Decomposition and relationships: In these models, we decompose the business functions, processes, activities, and tasks; identify the relationships to the information required to perform the business processes, and the systems (manual or automated) that serve up the information.
  • Areas for Improvement/Reengineering: Through this decomposition and identification of relationship between business/data/systems, we are able to identify gaps, redundancies, roadblocks, and opportunities in doing our business efficiently and effectively. Once identified, we can then tweak or wholly reengineer the business processes, fill in gaps, eliminate unnecessary redundancies, and so on.

Similar to the OMB Exhibit 300 “Three Pesky Questions,” DM Review reminds us that we cannot just focus on systems to fix what’s wrong in our organizations.

  • “Keep in mind that for almost every process evolution exercise, there will be more than just systems change (IT change) required. Organizational needs and personnel skills must be accounted for. It the organizational dimension is ignored, there will be another story about failure in process management and business change.”

Business Process Management is essential to organizational change management.

  • If a business is to be responsive to change and remain competitive, its ammunition will come from its ability to inspect, analyze and forward-engineer its processes and its business…before its competition!

So whenever you think of enterprise architecture remember business + IT, and the business comes first!


Share/Save/Bookmark

April 25, 2008

Enterprise Information Architecture

We all know that enterprise architecture is a strategic-level synthesis of business and technology information to drive enhanced decision-making. To develop the EA we must build out the individual perspectives, such as performance, business, information, services, technology, security, and human capital. This blog focuses on one of those, enterprise information architecture.

Enterprise Information Architecture (EIA) is the strategic-level information architecture for the organization.

Note: Information refers to both information (processed data) and data.

GOAL:

The overall goal of EIA is to provide the right information to the right people anytime, anywhere.

MANDATE:

Legislative:

The federal mandate in law enforcement is the Intelligence Reform and Prevention Act (IRTPA) of 2004. Further, The Office of the Director of National Intelligence (ODNI) has developed the Information Sharing Environment (ISE) Implementation Plan in 2006 and the Department of Defense created the Net-centric Data Strategy in 2001.

Common Sense:

We need information to perform our mission/business function and processes: we can’t do without it! Moreover, in an information economy, information is power and information is currency.

PROCESS:

Developing the enterprise information architecture is an outgrowth of developing the business, data, and system models to understand the business processes, the information required to perform those, and the systems that serve up the information.

According to the Federal Enterprise Architecture, Data Reference Model, there are three parts to developing your information architecture.

  1. Data Descriptions—identify what your information needs are.
  2. Data Context—determining how the information is related.
  3. Data Sharing—developing the mechanisms for discovering and exchanging information.

Data Descriptions is the semantics and syntax. It involves developing your “data asset catalogue” and the metadata. This includes developing a lexicon or data dictionary with harmonized terms and schemas to describe them, as well as tagging the data. This helps define what the terms mean and identifies the rules for arranging them.

Data Context is the relationships. It includes categorizing the information using taxonomies and ontologies. It includes developing models, such as entity relationship diagrams (ERDs) to identify entities or information objects (and their attributes or properties) and associating them.

Data Sharing is the transactional processes. It entails the decomposition of information exchanges (in an Information Exchange Matrix or in a Information Exchange Package Description, IEPD) to determine the provider, the consumer, the trigger, the frequency, the media, the security, and so forth for each type of transaction. This phases also includes developing information repositories/registries, information sharing access agreements, and other mechanisms for sharing the information, such as portals, web services, enterprise service bus (ESB), and so on.

In the end, EIA is about transforming the organization: Culturally, from information hoarding to information sharing; from a business process perspective, optimizing information flows and usage, and in terms of governance, managing information as an enterprise asset.


Share/Save/Bookmark

March 26, 2008

The Enterprise is Unwieldy and Enterprise Architecture

Enterprise architecture develops the architecture for the enterprise, right? You’d think that’s a no-brainer. Except what happens when the enterprise is so large and complex that it defies the efforts to architect it?

Federal Computer Week (FCW), 24 March 2008 reports that Dennis Wisnosky, the chief architect and chief technical officer for DoD’s Business Mission Areas states that “the Department [of Defense (DoD)] is too large an organization to attempt to encompass all of its activities in a single enterprise architecture.”

Similarly, FCW, 26 November 2007, reported that “the size of the Navy Department and the diversity of its missions make it impossible to describe the service in a single integrated architecture.”

Dennis Wisnosky goes on to say that “DoD must achieve business transformation by breaking off manageable components of an enterprise architecture rather than trying to cover everything at once…[this is how we will achieve] the goal of an enterprise architecture [which] is to guide future acquisition and implementation.”

Richard Burk, former chief architect of the Federal EA (FEA) at OMB states: “there is no practical way to create a useful architecture for a large organization. You can get an overall picture of an agency using an [enterprise architecture] of everything the agency does, but when you get down to making it operational, at that point you really need to break it down into segments, into the lines of business.”

The Navy is using the concept of segment architecture, but is calling it “architecture federation.”

Michael Jacob, the Navy’s chief technology officer, “compared the architecture effort to the development of a city plan, in which multiple buildings are built separately, but to the same set of standards and inspection criteria.”

Mr. Jacob continues that “our effort will allow common core architecture elements [technical standards, mission areas, business processes, and data taxonomies] to be identified so that architecture efforts can be aligned to those same standards.”

I believe that every level of an organization, including the highest level, can have a architecture, no matter what the size, and that we should tailor that architecture to the scope of the organization involved. So for an organization the mega-size of DoD, you would have very little detail in at the highest level, EA (like the FEA Practice Guidance demonstrates), but that the detail would build as you decompose to subsequent layers.

For any organization, no matter its size, every level of the architecture is important.

Within the enterprise architecture itself we need multiple views of detail. For example, from an executive view, we want and need to be able to roll up organizational information into summary “profiles” that executives can quickly digest and use to hit core decision points. At the same, time, from a mid-level manager or analyst view, we want and need to be able to drill down on information—to decompose it into models and inventory views--so that we can analyze it and get the details we need to make a rational decision.

Similarly, within the overall architecture, we need the various views of enterprise, segment, and solutions architecture. The enterprise view is looking at strategic outcomes for the overall enterprise; the segment view decomposes this into actionable architectures for the lines of business; and the solutions architecture “brings it all home” and operationalizes the architectures into actual solutions.

Just like with the profiles, models, and inventories of enterprise architecture where we can roll-up or down, the key with these various architectural levels is that there is line-of-sight from the enterprise to the segment and to the solution. The lower levels must align to and comply with the levels above. This is how we achieve integration, interoperability, standardization, and modernization.


Share/Save/Bookmark

February 19, 2008

Presentation Style and Enterprise Architecture

User-centric Enterprise Architecture employs principles of communications and design, such as maximizing information visualization in making information products useful and usable to the end-user.

In ComputerWorld , 24 September 2007, Michael Hugos, a principal at the Center for Systems Innovation, presents “Five Diagrams Beat A Victorian Novel.”

The article states: “Consider two methods of collecting and presenting computer system specification [or apply this to presenting enterprise architecture] to users. One is far more likely to result in disastrous development projects plagued by miscommunication and users who are unhappy with the systems that are developed to them.” This disastrous method for presenting IT, Mr Hugos calls the ‘Victorian Novel’ is based on “text specifications for systems development [and] it simply mire readers in a swamp of boring words.”

This method uses Unified Modeling Language (UML)…”they rely on use cases that seem very rigorous yet manage to reduce everything-from trivial details to important processing logic—into a monotonous blur of text that few people can read for more than a minute or two. The only diversions from this text are some abstract charts. UML documents seem to purposely designed to confuse and disengage the typical business user.”

I do believe Mr. Hugos could be equally describing traditional EA “artifacts” that mire the users in eye sore diagrams that cover entire walls or fill boxes and are they typical architecture shelfware that defies general readability, usability, and do not meet end-user requirements for information that adds value!

Mr. Hugos goes on to describe his method for presenting IT information, which aligns beautifully with the User-centric EA approach.

He states as follows: “Instead, I use a method based on the old saying that a picture is worth a thousand words. I use schematics and diagrams that give both business users and developers an easy way to understand the system under development [applies as well to EA].

Here are the five diagrams proposed:

  1. Process flow diagram—excellent, get the processes ironed out before automating, and enable business process improvement and reengineering.
  2. Logical data model—yes, capture the data requirements as the driver for the system solutions to serve up the information.
  3. Screen Map—right on, provide the end-user a storyboard of screens that show how they will interact with the system; that is User-centric.
  4. Systems architecture diagrams—nice, what is the technical infrastructure that underlies the system.
  5. Software object model—not one that I am familiar with, but sounds like it supports systems interoperability. It “defines the processing logic for the custom code and the data interfaces between custom software objects and packaged software.”

The five diagrams that Mr. Hugos proposes “enable effective communication between business and technical people so the system that gets delivered meets user expectations”.

It is truly wonderful to hear about architecture diagrams that are not typical shelf-ware, that help meet user requirements, that add value, and that are based on sound principles of communication. All too often these areas of architecture development are overlooked and at great expense to the enterprise and the end-user!


Share/Save/Bookmark

July 24, 2007

Separate Forest From Trees - Rule of Thumb #4

Rule #4 is separate the forest from the trees.

What this means is that we provide the users EA information in various levels of detail that is tailored to their particular needs in the organization. Moreover, each level of information is drillable (or clickable) to the next, so that user can navigate between information views.

For example, in our agency, we use a three level metamodel representing high, medium, and low, or what we call, profiles, models, and inventories.

  • Profiles are high-level, big-picture strategic views of the information; it’s the satellite view from 30,000 miles up, providing information to the executive in a quick, condensed format, usually a graphic.
  • Inventories (or catalogues) are the detailed views of information usually in database or spreadsheet format, that is typically used by the analyst. It’s the trees versus the forest; the distinct configuration items with lots of information about each one.
  • Models are the connection between the forests; they illuminate relationships between information that is especially useful to the mid-level manager working with his/her peers. These relationships include those that show how processes work, how information is exchanged between entities, or how systems interoperate.
In user-centric EA, it's not one size fits all!

Share/Save/Bookmark