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

June 8, 2008

Cognitive Styles and Enterprise Architecture

We are all familiar with personalizing websites like Yahoo.com to make them more appealing, functional, and easy to navigate.

Now, according to MIT Technology Review, 9 June 2008, websites are being personalized not by the person, but rather by systems “that detect a user’s cognitive style” and changes the website accordingly

What is cognitive style?

Cognitive style is how a person thinks. Some people are more simplistic, others more detail-oriented, some like charts and graphs, and some like to be able to see and get to peer advice.

Why is cognitive style important?

Well, if we can figure out a person’s way of thinking and what appeals to them, then we can tailor websites to them and make them more useful, useable, and more effective at selling to them.

“Initial studies show that morphing a website to suit different types of visitors could increase the site’s sales by about 20 percent.”

So what’s new about this, haven’t sites like Amazon been tailoring their offering to users for quite some time?

Amazon and other sites “offer personalized features…drawing from user profiles, stored cookies, or long questionnaires.” The new method is based instead on system adaptation “within the first few clicks on the website by analyzing each user’s patterns of clicks.”

With cognitive style adaptation, “suddenly, you’re finding the website is easy to navigate, more comfortable, and it gives you the information you need.” Yet, the user may not even realize the website has been personalized to him.

“In addition to guessing each user’s cognitive style by analyzing that person’s pattern of clicks, the system would track data over time to see which versions of the website work most effectively for which cognitive style.” So there is learning going on by the system and the system gets better at matching sites to user types over time!

If we overlay the psychological dimension such as personality types and cognitive styles to web design and web adaptation, then we can individuate and improve websites for the end-user and for the site owner who is trying to get information or services out there.

Using cognitive styles to enhance website effectiveness is right in line with User-centric Enterprise Architecture that seeks to provide useful and usable EA products and services. Moreover, EA must learn to appreciate and recognize different cognitive styles of its users, and adapt its information presentation accordingly. This is done, for example, in providing three levels of EA detail for different types of end-users, such as profiles for executives, models for mid-level managers, and inventories for analysts. This concept could be further developed to actually modify EA products for the specific end-user cognitive styles. While this could be considerable work and must be balanced against the expected return, it really comes down to tailoring your product to your audience and that is nothing new.


Share/Save/Bookmark

May 24, 2008

The Business Analyst and Enterprise Architecture

A business analyst or "BA" is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of [IT] services to the enterprise. (Wikipedia)

Business analysis is critical to enterprise architecture, because it derives the business functions, processes, activities, and tasks. Coupled with some basic data and systems analysis, BA determines the information requirements of the business and the systems (manual or automated) that serve those up. Through business analysis, we identify gaps, redundancies, roadblocks, and opportunities which are used by enterprise architecture to drive business process improvement, reengineering, and the introduction of new technologies.

Where does the business analyst reside in the organization—in the business or in IT?

The answer is yes to both. The business analyst resides in the business and works on segment architecture for their lines of business and on defining functional requirements. Some business analysts also reside in IT as a relationship manager to translate business-speak to the techies and vice versa. Also, the LOBs may not have business analysts on staff and may request this service be performed by the IT shop. For example, this may be done from the enterprise architecture function to support segment architecture development or alignment to the enterprise architecture. Or it may be done by the IT centers of excellence that develop the systems solutions. If they can’t get the functional requirements from the LOBs, they may send in their own BAs to work with the programs to help capture this information.

ComputerWorld Magazine, 12 May 2008, asks “Is there a place for business analysts in IT today?” And answers, “Not if their primary function is just to analyze business needs…business people want more than analysis; they want workable solutions.”

So aside from business analysis what do you need to come up with a technical solution?

  • Resources—$$$$, smart people, the right infrastructure! (this one’s mine, the other two below are from ComputerWorld)
  • Creativity—“come up with ideas…to create systems that can meet performance requirements.”
  • Synthesis—“best ideas are evaluated and modified until good solutions are found.”

According to the ComputerWorld article, a single person who does the analysis, the creativity, and the synthesis is called a systems designer, but I disagree with this. The analysis and development of the requirements is “owned” by the business (even if IT is called upon to help with this function). While the creativity and synthesis, which is the technical solution, is “owned” by IT. Further, it is typically not a “single person” that develops the requirements and comes up with the solution. The solutions provider (IT) is generally distinct from the business that has the needs, even if sometimes it is difficult for them to articulate these into functional requirements.

ComputerWorld specifies four techniques for identifying requirements and developing a solution:

  1. Group facilitation—“getting input from everyone who might have relevant information and insights on a business process.”
  2. Process mapping—“create diagrams that capture task sequences for existing and new workflows.” (I believe we in EA all know this as Business Modeling).
  3. Data modeling—“diagram the structure of the data those workflows operate in.”
  4. User interface prototyping—“use prototypes of user interface screens to illustrate how people can interact with the system to do their jobs.” (Frankly, I don’t believe this one fits with the other three, since prototyping comes somewhat down the road in the SDLC after conceptual planning, analysis, and design. I would replace prototyping with some core system modeling to fill out the business, data, and system model set, so that we can see what systems are currently in use and where the gaps and redundancies are, and where there is potential for component or system re-use and building interoperability.)

I would suggest that 1 and 2 (the facilitation and business modeling) are the functions are the business analyst, but that 3 and 4 (data and systems modeling) are the responsibility of the IT function. Again, it is the business that “brings” the requirements and the IT department that comes up with the technical solution to meet those requirements.

Another thought: Perhaps the organization is struggling with defining the business analyst and those that develop the technical solution because it is really the synthesis of the two that is needed. It is similar to enterprise architecture itself, which is the synthesis of business and technology to enable better decision making. I can envision the further development of segment and solutions architecture to become just such a function that merges the requirements (business) and solutions (IT).


Share/Save/Bookmark