>Check out this SlideShare Presentation:
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.
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.
There are three levels of architecture in the organization: enterprise, segment, and solutions. This is explained in a prior post.
Each level of the architecture identifies and categorizes business and technical information. However, the information captured in the three architecture levels (enterprise, segment, and solutions) differs as to their level of detail.
Here’s how this works:
- Catalogues—Enterprise architecture maintains catalogues of strategic-level enterprise assets. For example, EA provides catalogues of enterprise business functions and activities, enterprise systems, and enterprise hardware and software products and standards.
- Portfolios—Segment architecture maintains portfolios of items scoped to the individual lines of business (LOB), at a medium level of detail, with impact focused on business outcomes. For example, a portfolio of systems or databases relevant to the functioning of a specific LOB such as for Finance, HR, and so on.
- Inventories—Solutions architecture maintains inventories of configuration items for the enterprise. The configuration items are at the maximum level of detail for maintaining control of changes. This is used, for example, for software configuration management and for engineering support of IT infrastructure.
All three types of information products types—Catalogues, Portfolios, and Inventories—contain similar types of information pertinent to the organization; however, each product functions at a different level in the architecture—enterprise, segment, and solutions. Each of the information product types should be traceable and align to the next, so that inventories roll up into portfolios, and portfolios roll up in total to the enterprise asset catalogues. In this way, the architecture framework is consistent throughout the organization, items are traceable at all levels—from the solutions developers up to the strategic-level EA—and items can be viewed at the appropriate level of detail depending on whether the viewer is a senior leader, an executive decision-maker in the LOB, or a solution provider (“fixer-doer”).
Some organizations have chosen for simplicity’s sake to call all three of these product types “inventories.” That is acceptable, with the understanding that these “inventories” are providing different levels of detail corresponding to the different levels of architecture.
- 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!