Intellectual Arbitrage Group: Website Redesign

intellectual Arbitrage Group’s Office365 Small Business Premium website V0.7

Spent a few minutes each day this week working on Intellectual Arbitrage Group’s new public website.

intelarbgrp-website-homeOffice365 Small Business Premium IAG Contact Up Page Design

It has taken a little while to get some time on my schedule to work this activity.  Like other small consulting firms,  Time to work on marketing, backoffice systems, and practice development is always in short supply when you don’t have a dedicated people working each task.  Fortunately, using most of the Office365 Small Business Premium templates means I can focus on content and customers instead of presentation.  Only wish it had more flexibility or useful help on how-to customize like WordPress.comto is very minimal.  While the library of SharePoint web parts is helpful, the flexibility of these parts is minimal or not very well supported by documentation.

IAG-Office365 Website WP Blog-Webpart

This past Sunday, I asked my DNS Hoster [ZoneEdit] to build new records to forward my URL and Mail over to my Office365 site.  Both Registrar [DomainPeople] and DNS name service [ZoneEdit] were very fast and responsive, I switched over to new services in less than two hours.  I only hope Microsoft can match that Service Level, though I didn’t see a clear Service Level Agreement (SLA) from Microsoft when I signed up.  But then again they are still new to Services.

Creating Workflow for Modern IT Portfolio Management

On this week’s agenda is building out the workflow for the IT Portfolio Management Practice.  Unlike how IBM, DMR, and Microsoft accomplish practice implementation, I plan on creating a semi-automated workflow using SharePoint, MS Access and Excel.  While using PowerPoint and Word templates may capture content and present it in a “pretty” way, it does nothing for ensuring the quality of the output.  That was one of the reasons I created B.A.S.E. years ago.  I had gotten disgusted back then with the quality of analysis peer consultants were performing, choosing to spend all their time on formatting.  I guess I shouldn’t complain about such, as it created a market for me back then; fixing all the poor engagements and projects these people performed.  I’ve see lots of “pretty” engagements go bad due to poor analysis and thinking which creates the ultimate consulting sin in my book; doing harm to the client.  Having a structured process and supporting system may not guarantee perfect results or avoidance of harm, but it sure reduces the probability and provides better visibility to detect such.

Translating Business to Enterprise Architecture: Methodology Activity #2

Capabilities from this context are the “what do we need to be able to do” to enable the strategy.  This requires more thought than just saying we need the capability to collaborate.  Collaborate by itself is just an activty with no context. If we add a software application associated with collaboration we’re still not talking about a real strategic capability.  There is a lot still missing from such a short capability definition.  To be effective a capabilities definition should contain what activitiy, who is envolved, what is to be accomplished and how. 

 Using capability to collaborate as an example, it would be neccicsary to define the what and who of collaboration.  This could be “we need to have our marketing staff around the country collaborate on collecting and analyzing market intelligence to determine new opportunities”.  This moves the definition from a broad and vague initiative to a supportive activity that could be associated to a strategy such as “the enterprise being more market agile and adaptive than competitors”.   When associated with this strategy those in the organinzation can see why collaboration capability is important and how it should be implemented. 

This definition also brings to the surface that developing a capability is more than just providing technology, it infers that there are people to be envolved with skills and knowledge, information that needs to be supplied and further sub-activties to be accomplished other than just sharing the base information.  This underlying information with the objective of usage or what is to be accomplished provides the context on how the capability is to be used to provide the what of the satrategy.  With this context established the further refinement of creating the capability by selecting the technology, configuring its, and informing staff on its usage is kept in alignment with the strategy.  Too many technology driven projects often are successful in deployment of software, but fail in implmentation for te business.  Further research had shown that while the technology was functional, its usage was never thought of or publized in context to the enterprise strategy.  In some exterme cases the implementation and thereby adoption was actually counter to the enterprise’s goal.  As such while capability discussions seem simple these are crictially important and is where most of the loss of value occurs.  It is my believe this is where most initatives start going off track and further deviate from the path as the activities move from the abstract to the concrete.

Enterprise Architecture: The more we change, the more we stay the same

Last evening I started reading Business Architecture, Ulrich & McWhorter.  I was amazed at seeing the concepts I once extolled over a decade ago in my ZIFA presentation in print.   My mentor John Zachman back then had asked several provoking questions prior to then.  One was just confirming completeness his model of IT Architecture.  This was when time and motivation columns where not part of the framework.  We had several days’ discussion about what do time and motivation artifacts look like.

I would fall back to my dwelling architecture career of the past to answer; building schedules to name one, project plans to name another; both are concern with time or precedence of activity.  But is it important enough to be a dimension John asked.  It fits the reporter’s interrogatives: Who, What, Where, When, Why and How that I believe should be the columns.  “Did you ever think how hard and expensive it is to put a roof on a building without walls or a foundation.  It can be done, but it’s costly.”

The next one had to do with span and depth of Architects.  This was one of the most enjoyable discussions I had with John.  I had brought an old Architecture text book, creating architectural theory, Jon Lang.  In it Lang had described different levels of design, the span and granularity that architects of various types dealt with.  An Urban Planner is not about to design your house and his work products are likely to affect people for generations, look at how various city growth patterns.  These were established decades ago.  

Enterprise Architecture is much the same way.  Many corporations’ architectures are still the same, despite the addition of information technology.  These companies may or may not need to change depending upon the ecosystem they reside in.   However, as ecosystems start to interact with other ecosystems –think globalization—business models and architectures are exposed to others which may be more competitive.  Consider the “Japanese Auto Invasion of the 70s”, was it cheaper cars though cheaper labor as the Detroit elite suggested or was the old mass production model breaking down in the like of a different business model.  History now confirms the later.                  

When I present on Enterprise Architecture around the global, I still use the analogy of dwelling architecture.  The example I typically use to differentiate architecture from design and there is a difference is the various Gothic Cathedrals.  If you overlay them on top of each other each is different.  So it’s not the stone, glass and wood, but how you use these that determines an architecture.  These rules (Design Strategy aka Architecture) determine how the components relate to each other as well as usage of these as a system.

Going back to my technology example, consider the telegraph.  During its introduction it changed how business work around the nation and eventually the globe.  Now consider the next advance in communications technology, the telephone.  Initially productivity didn’t increase with its introduction.  Why?  Consider the old –in the relative sense—paradigm of the telegraph in business usage.  A business owner or manager would dictate a memo to secretary; she would courier it over to the telegraph office where it would be translated into dots and dashes; at the other end the dots and dashes would be translated back to text; couriered to the recipient business’s secretary who would read it to the business person.   Enter the phone; a secretary would take dictation then call the business at the other end, the two secretaries would exchange pleasantries and then dictate the information; which was then either handed to the other business owner or read to him.  During each of this information exchanges misunderstanding and transcription errors could occur.  A simple business transaction could take several days of back and forth.

It wasn’t until two business people broke the model and spoke directly to each other that a competitive advantage ensured.  Those business people that used the technology in a different way become more competitive.

Back to Ulrich & Whorter, they rightfully point out that SOA and Cloud are hyped as the next Holy Grail.  I believe they miss the mark though by tagging vendors and IT groups as the black hats in this story.  These stakeholders are both part of the problem and the solution.  However, business people share a lot of the blame as they continue to look for the silver bullet so they don’t have to think about managing their information or constantly reviewing and revising their business models.  Vendors and IT groups deal with information technology, not information management.  If you substitute drill presses, stamping machines, and an assembly line for servers, networks, databases and browsers we’re back to its not the stone, glass and wood but how you use them.  Vendors and IT shops are good to great at dealing with the mechanics, not so good on defining business models.   This is where Enterprise Architects come into play.  Unfortunately too many EAs are not EAs; they have the title but not the orientation.  They’re just technology or infrastructure architects with an inflated title. 

Failure to understand how to use the new technology in a new way will result in the creation of what my friend John Mancini of AIIM has labeled the Digital Landfill and create more of an Information Glut (think of hardening of a corporation’s knowledge arteries).         

You know you have an EA on your hands when s/he looks at business models & goals, economics, technology paths, organizational capabilities and how to translate these into a series of state changes for the company.     

What I still see on the horizon is Information Management Maturity.  Today I see signs that some organizations are seeing that need.  2020 Roadmaps talk to managing information more like assets.  Disciplines like Information Architecture while popular are still in its infancy, you’ll hear terms like taxonomy and ontology however, these are just exploratory projects in many corporations.  Technologies like SharePoint that could exploit the design intent that these terms represent are left waiting for the discipline to mature as well as a strategic execution system to deploy. 

    

For those of you wondering, these slides were presented in 1996 at the ZIFA conference

Rediscovering Information Management Methodology

About a century ago –no I’m not that old—companies were using advance information management tools called paper, file folders and filing cabinets.   Much of the daily course of business was concern with moving physical parts and products.  The movement and storage of information was also a physical effort; paper and files were routed throughout the organization which contained the information needed to monitor and control the organization. 

A gentleman Frederick Taylor came on the scene.  People either praise him or curse him now as he introduced the practice of scientific management which was instrumental in introducing the management consulting practice.  Later Marvin Bowers of McKinsey fame improved upon the practice. 

Mr. Taylor’s approach seems like a simple idea today, but it radically changed the landscape of industrial work and today is influencing information work (aka Information Worker).  The approach was to find the most efficient step of steps to accomplish a task, document and train others to use follow it thereby optimizing the time to output ratio.

Today we’re posed to accomplish similar automation for workers using information.  The problem that arises is that those in I.T. are ill prepared to accomplish this task.  Sure Developers and I.T. staff can lay down code to create a sequence of steps a computer will repeat at lightning speed till the cpu fries itself in some distant time.   The problem comes into play when you realize most programmers know software, software tools, and hardware, but don’t know your business. 

This is where business architects and analysts come in.  Analysts spend time learning how businesses conduct work and reduce these down to a set of descriptions in a standard language that programmers can further translate into computer-ease.   Architects look identify patterns and replicated them to accomplish similar work across the corporation.  Thus they are for lack of a better term super-analysts.

This entire preamble is to reintroduce a simple concept.  When management consultants where called in years ago, one of the techniques they used was to toss out every form in the place.  Next they would ask staff to create forms only when they needed them and only contain the specific information they needed to accomplish the immediate job.  This had the ability to streamline processes.  The past few decades’ variations of this approach have hit the BPR and IT domains with mantras like “simplify and automate”.  The question become at what level of simplification or generalization should one stop at.

Tonight I’m working on developing two SharePoint implementation architectures which will become these company’s operational infrastructures. [Yes, I’m crazy enough to two projects simultaneously]  Fortunately both are new, small firms, so much of the politics and complexity have not developed yet.

So how to start?  My typical approach has been to identify quanta of information that is produced and used throughout the organization, then document how these are created, distributed, used and disposed of.  Now my data-oriented friends will cheer at that.  However, my process-oriented friends will point out that I’m documented processes also.  And if the rest of my friends across the Zachman Information Architecture spectrum are reading yes, I go through all the columns with special emphasis on why.

Being I’m translating this to a SharePoint implementation, I’ll define these quanta as “Content Types” and define the attributes that are required for each. [My Information Architecture colleague Carol Corneby] will be happy.   This is where translation from business architecture and SharePoint design overlaps and transitions.   SharePoint developers will now start to understand what must be build.  Concepts such as information flows and stores will be converted to libraries –which are nothing but viewports limiting enterprise data to the subset a business person using the system needs—and workflows that are subsets of the business process or the value chain an enterprise manages to operate the business.

The methods for identification and translation of these abstractions and the conversion process is what I hope to eventually explicate this year as I’ve been doing this so long as have other peers like Ruven Gotz that we just do it without a second thought.  As we continue our SharePoint Salons our objective is to accomplish this and disseminate the information to others.                              

Information Maturity and I.T. ROI

I spent the beginning of my morning preparing for an ISV Product Assessment Deep Dive and reviewing some old Gartner group reports.  I’m an Industry Analyst for two Research firms in my off time.   As I scanned the graphs in the Gartner report I noticed an interesting trend from year to year.  The amount of I.T. budget spent on business transformation – pundit-speak—for improved capabilities for the business continues to shrink, while infrastructure and maintenance costs continue to rise.  The figures quoted for 2003 were 19% for transformation.   During the 1970s new application development –old category name for business transformation—was hovering between 30% to 40%.

The interesting issue around this fact is that vendors are all over talking about virtualization and cloud, yet when I look at the benefits of both they’re focused around reducing the hardware maintenance and platform cost footprint.  Oddly enough that’s one of the least costly items in the budget.  A simple Pareto Analysis suggest developing and working on means to reduce software, specifically application,  maintenance costs would give a better payback.  Simply put a reduction of 10% of 90% is more than a reduction of 40% of 20%.

Hopefully Cloud vendors and tool purveyors will crack tat nut.  I am hopeful given enabling technologies such as AgilePoint and Concatenate.  However that presupposes I.T. organization move up the food chain from 1990s design patterns to present day.  A recent spot check has too many customers using SharePoint as a web frontend to a shared drive.  Simply put many organizations are managing files not information.

Last month I kicked off a project to produce a White Paper: From File Management to Information Management an organizational maturity road map.  During the SharePoint Salon in Anaheim this month many of the participants contributed towards that body of knowledge with the intent of developing a practice based on a sound body of work.  Hopefully the next Salon I hold in a few months will advance the discourse as much as the previous ones have.        

SharePointDirections Reports

Fresh back from SharePoint 2011 Conference, SharePoint Salon, SharePoint Sushi; now I am fired up.  During the conference Owen Allen and I discussed framing a series of reports for SharePointDirections to produce after October; that’s the easy part.  Now I’m assembling information on ISVs that I gathered during deep dives with each. 

We’ll be revising the SharePoint EcoSystem Map during November for publication on the SharePointDirections website.  The map will take on more of an Enterprise flavor given SharePoint’s acceptance as an Enterprise level platform with the introduction of 2010.   The first report under consideration will cover the information management segment, followed by the process and workflow segment.  However, I’ve yet to schedule deep drives with ISVs in that segment.

Our goal is to provide a qualitative assessment of products in each segment initially, position them on a grid to help clients make informed decisions, and eventually perform a qualitative analysis on each.  I know that later is a big task, participating in similar activities in the engineering software market.  Check out Cyon Research.  

In the meantime my personal Blog will still continue exploring concepts and issues around Enterprise Architecture as well as a collaboration area with peers.             

SharePoint benefits for End-users

SharePoint Saturday L.A. interview courtesy of Christian Buckley of Axceler a few months back