Search Results for: business model

Patterns

by

In addition to story narratvies, I’m planning to use ‘pattern’ format for describing the Change Design tools: Here’s an example that describes the Business Service Specification tool (BSS). I would also then go on to describe how it’s been used in two …

Actions Speak Louder Than Words

by


In the last episode of the ACME E&L story, we left the CIO, Colin Black, musing how he was going to explain Cloud-Native “Unicorn” thinking to the Exec Board. After a few moments of reflection he decided a two-pronged approach would be best:
a)  Gradually introduce new concepts such as “Safe Fail”

b)  Demonstrate he could deliver business-relevant outcomes quickly.

Pragmatically, he reasoned focusing on the latter was his priority. The current highest priority for the Board was the impending merger with ACME’s second largest competitor. The newly merged company, MACME Plc. would be launching in just a few weeks – and the Board decided it needed to establish a new corporate identity and culture from day one. The CIO suggested this would be an ideal time to move all employees to a new email and office tools platform. He reasoned that email addresses would change under the MACME brand anyway and it would also be a good opportunity to create a MACME Branded intranet portal to help build the new culture.

This episode of the story is an interview with the Project Manager, Mr Olivier Gris, leading the transition from Microsoft Exchange to G Suite at ACME E&L Ltd. Olivier has worked with the CIO in the past and is regarded by him as his most trusted PM. In this interview, with a technology journalist, Mr Gris explains how he led his team to get 10,000 employees to a single instance of G Suite in 10 weeks. He discusses the ups and downs of the project, and most importantly the lessons learnt. He also explains, right up front, why this project fits with the CIO’s “Think Like a Unicorn” mantra and how emerged as a trust-winning strategy for the CIO with the entire business.

This story is a real company and a real project. The company identity and the character’s names have been changed.

***

Why did the CIO decide to use Google G Suite?

“Several reasons; The CIO wanted to ensure IT was in-line with the retail Entertainment and Leisure business, where revenue directly proportional to service availability. And, in increasingly ‘Digital World’, he knew IT had a strategic role to play”.   

“The CIO has a bias towards Cloud (and Google’s G Suite, in particular, due to earlier successes). The firm was heading for a merger, and the CIO wanted to make sure the new merge-co (MACME E&L) would be ‘born into a Digital World’ from the get go. The company being acquired already used Google G Suite, yet ACME E&L, the acquiring company used Microsoft Exchange. So he felt it was a no-brainer to follow the one that already ‘lived’ in the Cloud”.

“He favoured for SaaS on the Cloud for 3 main reasons;

  1. The software is constantly updated – no massive change plans required, instead, lots of small increments; little triangles of risk as opposed to one big one.
  2. People were increasingly working from home and they wanted a consistent experience.
  3. Online collaboration would be far easier – anytime, anywhere”.
“The company being acquired already used G Suite, but had actually created three separate instances. This turned out to be a questionable decision for a number of reasons:

  • They outsourced a problem; a troubled service, taking its troubles with it.
  • Unfounded security fears; Head Office was concerned that the shop staff might take a more cavalier attitude towards security and compromise the whole business.
  • Not fully appreciating that G Suite was built with strict security policies in mind, which could be configured to prevent cross-contamination between the shops and the Head Office.
  • Not believing that Google’s DC level security was likely to be far more robust than anything the could implement in their own DCs. This motivated by the fact that a hack into Google would be a very newsworthy event compared to a hack into their DC.

 So, with those points in mind, he felt it was a ‘given’ go for one instance of G Suite for the whole MACME E&L business”.

Was there an ROI calculation for this project?

“No, there wasn’t a formal benefits case. Things were moving quickly,; the business had bigger-fish-to-fry with the impending merger. The merger was costing money on a daily basis, largely to do with the sale of real estate and conditions set by the regulator. So there wasn’t ROI per se. What convinced the Board was that running two different platforms would be crazy, and that deployment Cloud was low-risk for office tools. And that, combined with ‘The Sword of Damocles’ of day one of the merger, meant something had to be done fast. They also saw the value of one platform bringing staff together after the merger. For those reasons, the Board was happy to support the CIO’s recommendation without doing a formal ROI”.

What were the steps and how long did it take?

“The steps at a high level were a bit unusual, mostly due to complications imposed by regulator – we weren’t allowed to share any corporate data ahead of the merger as the regulator deemed they may be a risk of competitive advantage. So nothing between the two pre-merger firms could be shared before day one of the merger. They did, however, allow us to set empty email accounts for the company being acquired within ACME E&L. That meant running a mirror instance then switch to single instance later, and then merge two Google G Suite instances. This all took a while to agree with the regulator and resulting the final decision on how to handle the two firms data was made just 7 weeks before the merger. This created a challenging set of constraints on both pace and approach. In the end, we managed to transfer most of the data (held in a dormant state) in batches over 4 weeks”.

Is there a long-tail of users yet to adopt?

“We were close to 100% users set up and running within 8 weeks. One or two people might’ve been missed due to Maternity leave, or similar. But we think we have caught those by marrying up Active Directory entries with HR records”.

“We’re planning to fully decommission Exchange early in the New Year (around 10 weeks after go live). We need this extra time to recreate distribution lists, transfer archived mail, and deal with automated email-based workflows”.

“So, in summary, we went from zero to 98% of our users up and running on G Suite in 5 weeks – and the remainder 4-5 weeks later”.

How many users now?

“We now have around 10,000 users on G Suite since the merger. Around half of these transitioned from Exchange whilst the other half were consolidated onto a new G Suite instance. Interestingly, the Google to Google transfer was more technically challenging in some ways; the tools available for Exchange to G Suite are very mature, however, this wasn’t the case for G Suite to G Suite, so the latter was more ‘hand-balled’”.

What were the biggest hurdles?

“We had a few unusual issues to contend with; for example, someone in Asia had hijacked the domain name we wanted for the merged company. This meant we had to work with our legal team to get that fixed, and that added pressure to the schedule. But, I’d say the people related issues were the biggest. We had underestimated how fond people were of Microsoft Exchange email. It’s very mature and people like it. For many, Google G Suite was seen a step backwards; email is what they see every day and, at first, many didn’t like the switch to browser-based email. On top of that, they didn’t see the advantages of the move to G-Suit in things like collaborative and home working. To tackle this, we took a viral approach to adoption; we sought-out enthusiastic supporters and helped them spread the word. We ran ‘Right-Fit’ workshops with the users where we discussed the pros and cons of G Suite and shared ideas and use cases (from previous workshops). It was important to hear the user’s voice and, then help them get the most from the tools; these were not training sessions – they were interactive workshops“.
“Probably the most compelling use case for the shops was around Google Forms & Sheets; for example, data sets for performance, schedules and promotions could be shared with the Head Office & other stores, faster and more accurately using Forms and Sheets. This resulted in many hours of saved at the retail outlets”.
What was the user feedback?

“The user feedback from retail area managers has been superb. We conducted a few sample surveys after we’d run the ‘Right Fit’ workshops – the results speak for themselves: ratings rose from a mark of 1 to 5 before the workshop, to between 6-10 afterwards. Workshop attendees were asked to rate Google G Suite pre and post training (1 being ‘Poor’ and 10 being ‘Awesome’)”.

 

 

Figure 1 Feedback from area managers across two regions of the U.K.

 Southeast Region


Midlands



“

Feedback from Head Office staff was less enthusiastic at first. However, many are now seeing the benefits of collaboration and remote working.

We had to be realistic, not all users would like the change; for example, an Executive Assistant who manages multiple diaries finds this harder to do in Google calendar than in Exchange. Google Slides lacks functionality compared to PowerPoint, some complained about this, but others saw this as a good thing; they can focus on writing great content rather than be distracted by too many features and options. And then, there are some people, who just don’t like working in the Browser”.

 

What’s the best feature?
“I’d say Hangouts for Head Office, and Google Forms/Sheets for shops. Voice & video meetings on Hangouts becoming the norm. The users already understand the power of collaboration – both collaborative document building, and data sharing”.

What’s the least popular?

“The least popular app is Google Slides compared to PowerPoint and the management of multiple calendars. Other than that, spreadsheets with complicated rules and macros can be a challenge to recreate in Google Sheets. Having said that, some users are beginning to see advantages in using Sheets; for example, one recently built a spreadsheet that made use of easy access to other Google data to calculate the distance between two postcodes”.

“Uncovering large ‘Spreadsheet Apps’ was an interesting spin-off. We were looking deeper into the use of complex spreadsheets; these are the powerful spreadsheets, built by users, which have become important ‘Shadow IT’ tools that are now critical to the business operation. There’s probably a good argument to say these should be brought under more rigorous support as bona fide apps in the future”.

How does it fit the overall “What Would A Unicorn Do?” strategy?

“The retail industry has gone digital; our digital products are our lifeblood. This means the role of the CIO is more important than ever – and the Board is listening to the CIO. The CIO has made it clear that our move to the Cloud is key to improving service automation. The IT team must refocus on delivering outcomes for competitive advantage: ‘Build for Competitive Advantage – Buy for Competitive Parity’ is the mantra. In other words; ‘Don’t re-invent functionality that can be provided by commodity services’. Moving to Cloud-based offices tools is directly linked to the CIO’s strategy; He asks the question; Why don’t we manage IT services in the way the likes of that Amazon Netflix do?”.
From the CIO’s perspective, moving to G Suite was a tangible, and pragmatic step; a first move to digital without putting revenue generating systems/services at risk. This was his chance to show how his Cloud-native strategy will deliver results quickly. He could demonstrate tangible value, he believed he would show that: everybody in the firm would like the collaboration features, the shop staff would save time when sharing data and, for everyone, wasting time travelling to meetings would become a thing of the past. It turned out he was right”.

Did you feel the sense of strategic importance at the project level?

“Absolutely, we knew we needed to make new CIO look good, and it did the trick! Initially, there was a question about the wisdom of switching to G Suite in the midst of the merger, but we explained that we would be going through the pain anyway, so why not get it over with from the get go? We also helped make the case to take the opportunity to rebrand the merged company from day one of its operation; to access G Suite, users logged into to a new look & feel that told the MACME Plc story and the opportunity to collaborate with colleagues old, and new”.

Which of the CIO’s principles did this project support?

“The main principles we followed were:

The move to Cloud SaaS meant no more massive upgrades and, at the same time, providing services any time any place – at the desk, at home or elsewhere. The IT teams were not spending time on software upgrades and hosting of commodity services; the focus was on offering more differentiated services to our internal and external customers. We choose a tried-and-tested service from Google, and by Clouding rather than Outsourcing, commodity services were made much simpler to deploy and upgrade; we simply trust the provider to new helpful features and services incrementally, with no need for massive retraining programs”.

What were the IT savings?

“The IT headcount savings were minimal; a saving of around 8 outsourced FTEs. Rather than headcount reduction, people have more interesting jobs to do. In terms of assets, the Exchange infrastructure will be decommissioned in a few weeks time and we will reduce our CAPEX storage cost as we move away from shares on hosted disk”.
What has the project cost?

“The cost of transformation was about £1million. If you set this against roughly comparable yearly OPEX costs between the Microsoft Licensed model and the Google Service Fee model, and take into account the time saved across 5,000 retail outlets, the cost benefits case stands up. Not to mention the intangible benefits of improved collaboration, and anywhere working”.

Why Google G Suite over Microsoft Office 365 Azure?

“My last client was in Local Government, in their case they decided to switch to Microsoft Office 365.  Both the Google and Microsoft Cloud offerings stack-up against each other. The important point is, that in either case, software maintenance is simplified, as is the deployment of new functionality. We chose Google’s G Suite because the CIO had deployed it successfully before and was impressed by its simplicity and the rate of user adoption (particularly around collaborative working)”.

Are there organisations that should avoid SaaS office tools and if so why?

“Not many in my opinion. Organisations with highly sensitive data in – I’m talking ‘State Secrets’ here – would probably need special features and deployment models not available in commodity SaaS products. However, I believe, for most commercial organisations, their security concerns around the Cloud simply don’t stack up. Let’s face it, Google’s, Amazon’s or Microsoft’s Data Centres are going to be among the most secure in the world; they probably do a much better job of securing them than your company – a breach of security for them would be a much bigger headline!”.

“For a small business, it’s no-brainer!  However, at the other end of scale, companies with a lot of legacy ‘Shadow IT’ in complex spreadsheets and email-enabled workflow, might find the journey to SaaS more complicated and longer than ours.  For them, I’d recommend: the risk assessment be done scientifically, rather than emotionally, plan to implement in incremental steps, and listen and act on, user feedback at each increment”.
“Perhaps paradoxically, the tight time constraints imposed by the merger on our project was an advantage. The value of a single platform for the new company gained the attention of the Board, and that put pace and weight behind the project. I would recommend that any CIO thinking of moving to the Cloud find similar Board level support early on”.

“In summary, I would argue going Cloud is a much better way for delivering and managing IT services, and that a move to SaaS office tools is a relatively low-risk way to start that journey”.



Please follow me on LinkedIn or Twitter for future posts.
#horsesunicorns

Enterprise Architecture, Systems Engineering, and Regulations: Process Rudders or Process Brakes

by

Regulations: The “Must Meet” Requirements

Regulations directly affect all organizations, products, systems, and services. Further, they can be a rudder guiding the organization or a brake causing the organization to stop making any progress in meeting its charter, goal, or in completing its mission.  This post discusses laws, rules, specifications, standard, regulations (or simply regulations) as a part of any enterprise architecture or systems engineering effort.

The Customer Requirements Identification and Management tool that I’ve developed, CARRMA®, uses the concept of Must Meet requirements to store both the regulations and the metrics for meeting the regulation.  If more than one project has a particular regulation imposed on it, the CARRMA®’s data store will allow for reuse.

Regulations the rudders of an organization

Any commandment, law, rule, specification, standard, or regulation creates process friction, by its very nature.  It inhibits what can be done or defines what must be done. For example, saying “Thou Shall not Kill” means that it’s not nice to end a vehemently intense discussion by bouncing your opponent “six feet under”, though that might be very satisfying at the moment.  That is, killing is not a good solution to an intra-group disagreement since it doesn’t promote understanding, knowledge and therefore value growth of the group and doesn’t instill trust with other groups.

Hoping that I’ve made the point that regulations curb action or ensure action, by an over-the-top example, a regulation acts like a rudder, making it difficult for a process and thus a strategy to go one way, thereby making it easier to go another.  This, in turn, may directly affect the organization’s charter, mission, or goal.  In any rational system it should enable both the charter/mission/goal and the strategies and processes for achieving these.
Fortunately or more importantly, unfortunately systems and organizations built by humans are not entirely rational and sometimes not rational at all.  If the economy is the engine that powers the ship-of-state in an organization, then each commandment, law, rule, specification, standard, or regulation enacted is a rudder with its own wheel guided by part of the crew steering the organization toward their own Avalon.

Arrow’s Paradox and Catch 22s

At some point the number of rudders pointing at all points of the compass are such that the organization be it private or a ship-of-state either comes to a complete halt or turns in tight circles.  The rudders have formed a damn that effectively stops all forward progress of the organization, which no amount of churning by the organization’s economic engine can overcome.  Some of these regulation rudders are small and some are very large.  Twist the large ones hard and the ship brakes to a crawl and it may not turn at all. 

Arrow’s Paradox

A bigger problem is that too many regulation rudders will simply cause the organizational ship to stop and not make any of the ports.  Dr. Kenneth Arrow’s is known for “Arrow’s Impossibility Theorem” [Sidebar: For which he won the Nobel Prize], which is also known as Arrow’s Paradox.  He demonstrated mathematically that if an organization has three or more goals that they want to optimize, they will be able to only optimize on two (or I suspect they can sub-optimize on all three).

The point here isn’t that organizations can’t have more than one goal or objective; it is that if the organization attempts to define more than two (or maybe three) objectives using the “policy/regulation” strategy, the organization will slow down, wobble around, and achieve none of the objectives.

If you add in that in a democracy the goals and objectives change as controlling constituencies change, normally you end up with more and more laws, regulations, rules, and standards each attempting to use its regulatory rudder to change the course of the ship-of-state to reach the objective for which it was enacted.  The net result is that either the ship-of-state will end up on the rocks or going in circles.

From personal experience with federal contracts and from a recent DoD report, I can illustrate the problem.  One goal, which probably should be the only goal of DoD contracting, is to provide the most effective weapons in the world for the US Military.  That is, the weapons should be the greatest force multiplier.

However, the contracting office is faced with a second objective (a second rudder) of acquiring these weapons cost efficiently.  There are two metrics for cost efficiency, the initial cost (including research, development, and construction), and life-cycle costs (maintenance, upgrades, and disposal).  The question for the contracting officer is, “Do you contract for the cheapest initial cost product or for the one that will cost the least over the product’s projected lifespan?”

Then there is a third rudder in the form of the dependability of the product, system, or service. “Dependability encompasses all of the “illities”, including reliability, maintainability, serviceability, and so on.  Each of these has metrics and standards that must be met.  In some cases the metrics for the standard or policy is either untestable in a timely manner or in a few infeasible or impossible to meet.  All of these rudders will force addition time and expense into the effort.

A fourth rudder is reconfigurability and upgradeability of the product, system, or service.  Before the US Civil War, the rate of change of weapons and support systems was such that weapons and weapons systems had no need for this “Must Meet” requirement/policy.  The weapon would be worn out long be the technology changed.  However, since then it’s obvious that technology has and is continuing to accelerate (to the point that for many systems, they must be upgraded before their development and implementation is completed).  These continue to increase the initial design costs. [Sidebar: Services Oriented Architecture can reduce these costs greatly for IT systems, and modular systems/product can do the same for hardware of all types.]

A fifth rudder, and first one that is politically/social motivated as well as costly is the implied policy that all congressional districts and states should have jobs related to weapons and intelligence system development, especially where the senator or representative sits on committees dealing with budgets and military programs.  A recent DoD study has shown that this can add 20 to 25 percent to the cost of a product, system, or service for the DoD.
Then comes the politically motivated socially liberal welfare policy rudders (those intended to regulate social welfare and social change).  For weapons and intelligence tools, these require that a certain percent of the work on the product be from female owned companies and another percentage be from “minority” owned businesses.  [Sidebar:  The social actives’ idea was that the only way these groups could break into DoD contracting was through regulation.  I think they were correct because most of the work they did that I observed over the 25 years I was associate with government contracted engineering demonstrated beyond a doubt that they were incompetent to compete with a level playing field.  Many times the prime contractor had to supply the engineering capability to complete the job over schedule and way over cost.]  While it isn’t Politically Correct to attempt to define how much money was spent on this contracting welfare, from personal experience I expect that it is very significant.

The point of this section is not to discuss the problems with the regulations and informal policies of DoD contracting, rather it’s to demonstrate that as more laws, policies, regulations, business rules, standards, and so on (the “Must Meet” requirements) are imposed on a program, especially, extraneous ones, that both the effectiveness of product and the cost efficiency of the project or program are reduced.  And at some point there are so many “Must Meet” requirements that the effort, even at the enterprise architectural level will fail.

Catch-22

The extreme case of Arrow’s Paradox is the famous Catch-22 where two regulations are diametrically opposed leaving whatever effort, project, program, organization, or enterprise going in circles and making no progress in any direction. Even with a ship-of-state the size of the United States (which is a supertanker sized economy), given enough Catch-22s and nothing will get done; too many steersmen, too many rudders, and too many goals (targets, harbors, or whatever).

A good current and everyday example of regulatory Catch-22 is deicing roads.  Having icy sidewalks can be very exciting and occasionally lethal—so it really is not a good thing.  So deicing the sidewalks is mandatory.  Deicing calls for the use chemicals like sodium chloride (salt).

The problem is that there are regulations (must meet) requirements for the use and storage of “salt” because it “pollutes the environment” (and it does, you should see my grass near the sidewalk and road).  So you must use chemicals to save lives but you must not to save the environment.  Two regulatory “must meet” requirements (rudders) are in opposition, one to save lives and one to save the environment.  This is a small example of a big problem that can and will bring the economic ship-of-state to a dead stop.

Reducing the Number of Regulatory Brakes but Keeping the Rudders

To get any organization to at least head to a goal it should be clear that removing internal policies that interfere with the attainment of the goal is necessary.  For large organizations with many sub-organizations, the issue becomes one of identifying which regulations guide the organization in the direction its charter, goal, or mission state and which are braking it to a stop.  For many organizations, but especially democratic style governments, there will always conflicting goals and missions and therefore conflicting regulations.  So how should a large organization or government determine which are rudders and which are brakes?
To my mind, this is a good place to apply Enterprise Architecture and the architectural model that I set out both in my book and in this blog.  The nice thing about that architectural model is that it can start as a static model that can be used to identify customer requirements and end up as a dynamic model of the enterprise (even the Ship-of-State).  As such, it can identify policies that are braking or causing bottlenecks in the processes enabling the strategies for attaining the goal or mission.  Until you can dynamically model the enterprise, you will never really be able to identify the unintended consequences and negative externalities of any policy, standard, or regulation.  Nor, as the goal or mission changes can you identify those policies, standards, or regulations that truly impede progress in the changed direction (though many politicians in the organization will be able to tell you, or so they believe).

For those policies and standards internal to the organization, the leadership should be able to understand which regulations support the organization’s strategies and process and which don’t.  Additionally, the leadership can propose changes, deletions, and new regulations, which the enterprise architect can then model to determine the likely consequences, both intended and unintended.  Once the enterprise architects have oriented the changes the leadership proposes [Sidebar: See the OODA loop] the leadership can then choose what internal policies, standards, and regulations to change and which changes to implement with a much lower risk while seeing the their organization move more quickly toward achieving its goal.  [Sidebar: The modeling will also show where leaders and managers of sub-units are working on their own agenda which might or might not be steering toward the overall goal.  Remember the Systems Engineering axiom, “Optimizing the sub-systems sub-optimizes the system.”]

For governments, especially for the legislative branch, architectural modeling is particularly important both to determine conflicting laws, regulations, rules, standards and codes.  If, as the architectural models mature and their predictions help to make better decisions, there may even be fewer vehemently intense discussions about which laws, regulations, rules, standards, and codes to enact and which to remove or rewrite…Interesting.

Enterprise Architecture, Systems Engineering, and Regulations: Process Rudders or Process Brakes

by

Regulations: The “Must Meet” RequirementsRegulations directly affect all organizations, products, systems, and services. Further, they can be a rudder guiding the organization or a brake causing the organization to stop making any progress in meeting i…

Enterprise Architecture, Systems Engineering, and Regulations: Process Rudders or Process Brakes

by

Regulations: The “Must Meet” Requirements

Regulations directly affect all organizations, products,
systems, and services. Further, they can be a rudder guiding the organization
or a brake causing the organization to stop making any progress in meet…

If You Want to Create an Enterprise Architecture; Don’t!

by

One of the last presentations I made as an Enterprise Architect for a major DoD contractor was to the Chief Architect of the US Veterans Administration.  I walked in with a fully prepared presentation that was to take about 10 minutes of the time …

If You Want to Create an Enterprise Architecture; Don’t!

by

One of the last
presentations I made as an Enterprise Architect for a major DoD contractor was
to the Chief Architect of the US Veterans Administration.  I walked in
with a fully prepared presentation that was to take about 10 minutes of the
time…

If You Want to Create an Enterprise Architecture; Don’t!

by
One of the last presentations I made as an Enterprise Architect for a major DoD contractor was to the Chief Architect of the US Veterans Administration.  I walked in with a fully prepared presentation that was to take about 10 minutes of the time allotted to our team only to find the Chief Architect cutting the presentation off with a question, “How do we go about creating an IT architecture for the VA?”  Even though I had a very good answer and had applied it on a couple of occasion, my mind blanked.  I want to share with you his problem and the answer I should have given.


The Problem

The problem that the Chief Architect of the VA has is the same problem that plagues CA’s of all large organization and most of medium and smaller organizations.  That question is base on the very logical idea very much the analog of the idea that before you start changing the plumbing, you should know design of the current plumbing; that is, before you can create a “to be” or “next step” architecture you need to have a “current architecture”.  Obviously, if you don’t know which pipes connect where and start making changes to the plumbing you could end up with some very interesting and exciting results for which you may need to call your insurance company.  Likewise, if you want to improve the effectiveness and/or the cost efficiency of the organizational processes and information systems, most Enterprise Architects assume they must first define and delimit the “as-is” processes and information systems for the organization.


The conundrum is that, in today’s technological environment, by the time an IT architecture team has mapped out (structured and ordered) an “as is” architecture, some, most, or all of the elements and data of the architecture will be obsolete and out of date.  For something as large as a major corporation, a department within a state or the federal government, the cost and effort involved would require a tour de force on a very large perhaps unprecedented scale.  This cost and level of effort would be such that the senior management would cut funding to the effort as a waste of time and money, since having an “as-is” architecture by itself produces little in value to the organization.


As can be found in the literature, there are many ways to “solve” or at least ameliorate the problem of creating an “as-is” architecture.  For example, one of the best, that almost works, is to chop the organization into its components and create an “as-is” architecture for each component separately.  Then try to stitch the architectures together.  I’ve tried this and it works up to a point.


There is a truism in Systems Engineering, Systems Architecture, and Enterprise Architecture, “Optimizing the sub-systems will sub-optimize the system”.  I have demonstrated this to many people many times and experienced it several times.  But this is crux of the problem for those that try to create an Enterprise Architecture for a large organization.


The Solution

The simple answer is “Don’t”.  That is, “Don’t attempt to create an “as is” architecture for an organization, especially a large organization, because it will create itself with the proper procedures in place.  So how would I do it?


1. Define, delimited, and structured an initial set of classes and attributes for the Organization’s Enterprise Architecture.  These should include:

  • Its Charter, Mission, Goal

  • Its Strategies for achieving its charter, mission, or goal

  • Its Processes supporting its strategies

  • Its Tooling and infrastructure

  • Its Governance that affects any of the above, including:

  • Internal Policies and Standards

  • External Regulations and Standards

I worked with one Enterprise Architecture database that had over fifty classes, each class with ten or more attributes.  This was a fairly mature architecture.  My recommendation, don’t try to think of all the classes you may need or all of the attributes for each class; that’s way over thinking.  Instead, start simple and add through the cycles

2. Once you have designed and structured the initial set of classed and attributes, create a data base structured according to the design.


3. Here is the key to creating an “As-Is” Architecture by not creating it…Huh?  Design and implement processes to capture the current state of strategies, processes, and tooling/infrastructure as part of review of funding for revision and upgrades to the current systems and processes.  


4. When personnel in the organization propose a project insist that these personnel demonstrate the value of the process or procedure that they intend to update or upgrade. The “value” would include demonstrating which of and how the current product, system, or service enables the processes, strategies, and charter, mission, or goal of the organization. My experience has been that the initial attempts will be fuzzy and incomplete, but that as the number of proposed projects in the database (which is generally called the Asset Management System and on which the “as-is” architecture is built) increases both the completeness and clarity of the current enterprise architecture will increase.


The reason I say “Don’t” try to create an “as-is” architecture is that every 3 to 7 years every component of the organization’s information system will need replacement.  This means that within 3 to 5 years simply by documenting and structuring the inputs from all of the efforts the organization’s “as-is” architecture will be synergistically created (and at minimal cost) [Sidebar: There will be some cost because the project proposers will need to think through how their current charter, mission, or goal and the strategies they support links to and supports the overall charter, mission, or goal of the organization.  This is not necessarily a bad thing.]  For large organizations, no matter how much time or effort is put into attempting to create an “As-Is” Enterprise Architecture, it will take a minimum of a year and a great deal of funding; so it simply makes no sense.


As this Enterprise Architecture evolves you will begin to see a number of things that managers want to obfuscate or hide completely.  For example, a number of processes and component or sub-organizations will be demonstrated to be obsolete.  In this case obsolete means that the process or component organization no longer supports any of the organization’s strategies or its goal.  Since managers want to build or at least keep their fiefdoms they will not appreciate this much.  Additionally, it will demonstrate which internal policies, regulations, and standards help the organization and which hurt it in meeting its goal.  Again, the gatekeepers of these policies, regulations, and standards will object–strenuously.  


But there are two more insidious problems that a good “As-Is” Enterprise Architecture will reveal, nepotism and the famous “Catch-22s”.  


Nepotism

Nepotism in this case is more broadly defined than what most people think of as “nepotism”.  In the sense I mean, nepotism can include creating a non-level economic playing field. In all large organizations, but especially in the U.S. Federal government (probably in all governments) the type of nepotism I’m identifying is rampant.  In fact a December 2016 report from the Department of Defense highlights what most federal employees and DoD contractors have known for years, because representatives and senators will only vote for a large program if their district or state gets a part of it, the DoD estimates that the cost of the program increases approximately 20 percent.  This is “jobs welfare” on a massive scale.  Some major defense contractors have plants in every state for just this reason, not because it make any sense from a cost efficiency perspective.  Further, Congress had passed laws to ensure that minority and female owned businesses.  The reason is that minorities and women scream that the good old boy network doesn’t allow them to compete for sub-contracts [Sidebar: Actually the reason for the “good ole boy” network is that the prime contractors have sub-contractors that actually know what their doing.  In my experience, many times primes will “encourage”–read subsidize–inexperienced and frequently incompetent minority and female owned businesses in order to meet these regulations imposed on their proposals.]  Again, this is a form of social welfare to ensure all political constituents that scream loudly are appeased.  This adds up to the DoD being one of the larger governmental welfare organizations. [Sidebar: While, seemingly, I’ve picked on government organizations, especially the U.S. DoD, and while I have found that all governmental organizations in a democracy will have this type of nepotism.  This is what lobbing is all about.  Only when it goes so far that it’s plain to all and when it’s not openly enacted into law that we call it graft and corruption.]  And it’s not only governments that suffer from this type of nepotism, all large organizations have the same problems, though generally on a smaller scale.  For example, sometimes the nepotism is written into union contracts.  Along with finance engineering, the auto industry in Detroit suffered a near collapse due to contractual nepotism.

This presents a problem for any Enterprise Architect.  The as-is architecture will highlight the nepotism of this type more clearly than any report.  The Enterprise Architect won’t need to report it to the management, it will be self-evident.  I’ve experienced a situation, as I suspect many of you have, where the management kills the messenger in order to not address the problem.  In my case, three times I’ve been chased off programs when I reported that the effort was subsidizing silliness.


Catch-22

The second significant problem that policies, regulations, and standards become contradictory to each other or in combination make it impossible for the organization to achieve its goal.  Again, a good enterprise architecture will highlight these, though frequently, when management from one generation of technology with its set of policies and standards, finds the next upon them, they will refuse to resend or modify the existing regulations, preferring instead, again, to kill the messenger.  So like Systems Engineers, I’ve found that enterprise architects are only respected by other enterprise architects.


5. When the development and implementation team completes a project, and once it goes into operation, then as a final step in their effort, they should review the data they gave to the enterprise architect, revising the data to accurately reflect the “as-built” instead of the “as-proposed”.  The as-built documentation must include all component, assembly or functional, and customer acceptance testing, and all post production required changes.  This documentation will inevitably lead to additional class attributes of the Asset Management System and structure in the enterprise architecture.


6. As the Asset Management System and the Enterprise Architecture matures, management should prepare for a paradigm shift in the way projects and other efforts are proposed.  This is where Enterprise Architecture really demonstrates how it can make the organization both more effective and cost efficient.


A mature enterprise architecture can serve as the basis for a dynamic business or organizational process model for the organization.  Management can use this model to identify obsolete processes, (and as discussed) policies, regulations, and standards; ones that the organization should eliminate.  Additionally, with the help of the Enterprise Architect, management can identify missing or inhibiting processes and tools, and identify bottlenecks and dams in process flows.


Further, they can model what happens when the missing and inhibiting processes and tools are added or when the bottlenecks are eliminated or reduced.  This modeling will then indicate where there is a need for new efforts and to some degree the effectiveness and cost efficiency of such efforts.  It’s a paradigm shift in that no longer to component or sub-units of the organization propose changes.  Instead, senior management working with the Enterprise Architect and the component or sub-units will identify and fund efforts.  They now have a way to measure the potential of the change in meeting the organizational goal, which means senior management has a better way of managing organizational change.


Finally, once management has identified targets for change or upgrade, the enterprise architect together with a system architect can define alternatives to meet the effort’s requirements.  They can model alternative process and tooling changes to forecast which has the lowest potential risk, the highest potential return, the least disruption of current activities, lowest initial cost, lowest lifecycle cost, the most adaptable or agile, or any number of other targets defined by the senior management.  This will make the organization much more cost efficient, and perhaps more cost effective; and this is the purpose of Enterprise Architecture,


To sum up, using this six step, high-level process is an effective way to create both an Asset Management System (an “As-Is” Architecture) and an effective Enterprise Architecture process; perhaps the only way.  

Agility, SOA, Virtual Extended Enterprise, Swarming Tactics, and Architecture

by

Agility and the Virtual Extended EnterpriseIn the 1990s, The Agility Forum of Lehigh University defined Agility as “The ability to successfully respond to unexpected challenges and opportunities.” The forum chartered a technical committe…