Xentity holding Methodology Development review for ACT-IAC, Smart Lean Government

Blog post
edited by
Wiki Admin

Xentity, Methodology Development example (2002-2008 How TAA grew to MBT grew to OMB FSAM)

Over 6 years, it took several iterations of method, applying to projects scaling up method scope, application on programs/segments, lots of info sharing, and then promotion to base of FSAM. This is not to direct the Content of the ACT-IAC, Smart Lean Government (SLG) efforts, but how the method got developed, training material built out and trainer, how the team went out information sharing, promoting, and then helping apply to support true business transformation and modernization blueprints.

Summary of Objectives:
– Covered how Xentity and partners supported the Dept of the Interior iterate/develop the “Methodology for Business Transformation” showing some sample deliverables, templates, and visuals
– Discuss how we iterated from Bureau TAA (02-03) to DOI MBT (04-06) to OMB FSAM (07-08) through maturing from bureau, to agency, to federal through not only iterative method development, but through applying in iteration. First a few blueprints at bureau, then four at agency cutting across different driven blueprints (legal, organization development, target architecture, and shared services), then improving the method, and doing more blueprints, then doing more communications and training, and finally, promotion to OMB through collaborative integration with other methods.
– Cover lessons learned, critical success factors (i.e. framework agnostic, mapping to frameworks, culture understood, tested in 3 cycles of blueprints, breaking into services, first attempted foray into doing as NGO in 2006)
– Pitfalls (i.e. overselling, under training, lacking certification, didn’t emphasize earlier phases, limited bureau accountability, perception and politics, moving to FSAM – losing key aspects, calling it method instead of approach, perceived waterfall and not presented situational, training/maintenance budget limits)
– Cover things we would do now differently (i.e. wiki, more examples, more new Media communications)

Related Xentity links:

 

What do current disruptive technologies mean to the roles of the Federal CIO office

Blog post
edited by
Matt Tricomi

We wanted to ask: What do current disruptive technologies mean to the roles of the Federal CIO office? 

Currently the Counter Weights are in Legacy footprints, primarily legacy policy

Traditionally, the operating model and funding approach for IT has been based on the Brooks Act of 1965 and only added minor portfolio integration concepts based on the Clinger-Cohen Act of 1996. These acts were focused on internal IT cost-based centers, management information systems, mission control systems, and enterprise resource planning systems. These systems were all either internal mission or data processing systems used to run business. Since 1996, a lot has happened in the IT based. It has moved from cost center to profit center in the private sector and in the government space to service or profit center as well (i.e. profit for IRS in efiling). As normally is the case when shifting positions of an asset to the executive level, this also means the investment models change and shift as it is now a critical part of executing transactions and interactions direct with the public, yet our policies are now 20-50 years old.

A few general observations :
  1. The Federal experiment with Clinger Cohen and Circular A-130 addressing the role of the CIO and Enterprise Architecture has not neared fulfilling its objective. New strategies such as CloudFirst and Federal Shared Services are guiding investment, but not new roles of CIOs.
  2. The policy and roles need to be readdressed to manage disruptive technologies like shared services, commoditized cloud computing, information exchange or data and knowledge driven analytics and “who-knows-what-else” coming down the line.  
  3. The CIO’s shop has not been able to transform to meet the basic demands of security and infrastructure disruptions let alone attempts to solve the needs of the mission.  
  4. Additionally, Enterprise Architecture is and has been miscast and ill-defined within the CIO organization and as a result is being used for compliance reporting or to support internal CIO initiatives leaving the mission out in the cold.  

If these statements are agreed to be true, Is it a wonder that a nearly a dozen years after the circular was published that people are still asking “What is Enterprise Architecture”?  Or does the Capital Planning & Investment Control (CPIC) process really lend itself to shared services? Are these skills and tools in the right organization?

Opportunities abound if the right people are managing the disruptions

The federal government opportunities for improvement are many but the most valued will be floating betwixt and between the current organizational, process and data architectures – in the federal architecture ether. 
This poses an especially difficult task to the business.  The mission leaders need to be allocating skilled resources to understanding how to assess the value of disruptive technologies or service changes to address their goals.    It is old school thinking that the CIO as a service provider can penetrate their mission problems with the timely and appropriate application of technology.  The development of extensible cloud computing platforms with transparent accounting systems provides an essential key for the mission to step in, reposition itself, and own the movement towards shared services, enhanced information exchanges or improved mission processes.  After all, they are the immediate beneficiaries.

What might these new roles look like?

What might this look like from a 100,000 foot perspective? In a Business Week article, it summarizes the new role of the Federal CIO, historically an IT manager, is now:

 In sum, the successful CIO needs an intimate idea of how current technology can increase the company’s sales and not just reduce costs or improve clerical productivity.

Beyond the CIO role, there are several other key leadership roles to consider in new, coordinated policy.

  • The future CIO role should be targeted to managing infrastructure services and support shared mission services. The CIO can retain the acronym but in essence they should be managers of cross cutting infrastructure and once agreed to and designed and built by the business – shared mission services.  
  • The Chief Architect provides the analysis and design expertise to the Program Managers and Chief Knowledge Officer to help plan for the adoption of the disruption.  
  • Ultimate accountability for performance will be the charge of the Chief Performance Officer.  

In order to achieve true business agility while supported by the adoption of disruptive technologies and services, these roles will need to be figured out how to be repositioned to improve the government’s business capabilities and satisfy citizens, businesses, and cross-government customers.

What are some patterns or anti-patterns where architecture and governance can help

Blog post
added by
Wiki Admin

Architecture programs can be help to organizations – but for many different reasons. In same breath, by not identifying the needs for doing architecture, an architecture program can address problems that do not exist or leaders or team do not care about, and can become a waste of money or relegated to a compliance exercise.

At Xentity, we believe instituting architecture, governance or design guidance needs to address patterns, anti-patterns that create portfolio, solution and analysis management strategies that help deal with disruptions, investment in innovation, and shrinking budgets while improving services and aligning suppliers and partners.

Below are some example external pressure trends, common impact or anti-pattern trends cutting across cultural, business, and technology aspects of programs

  • Resistance to Change Planning: Intellectual approaches without balancing emotional or maturity context, not engaging leaders motives, pain, not seed-planting
  • Paving Cow Paths:  Automating management problems, function over form, not questioning assumptions, not looking at new (HR, IT, $) resource enablement patterns
  • Geek Speak Execs don’t get it, and its not their fault
  • Poor Modernization Blueprints: Mile-High, Inch-Deep, without proving pieces at time to gain momentum
  • Islands of Automation: aka Center of Universe – disparate sites, systems, apps, instead of services in user environment
  • Redundant Buying: Buying same item many times, no architecture  guidance to scale or change patterns

  • Program Management: Few delivered on time, on budget, on scope, on quality. Sponsorship lacking, not insuring/governing/buying risk, still not agile PM

  • Bad Data: Building GIGO Business Intelligence. Asking the wrong question of data which in turn leads to data collection failures.
  • Poor Cyber Security: IT security seen as lagging  IT cost, instead of asset-risk management issue
  • Too Much Change: Executives and Consultants promote constant flux, instead of unfreezing, adding change, and institutionalize new efforts and concepts
  • Problem seems insurmountable: Too large, complex leading to reversion to waterfall project planning techniques. The window for 2 years to test to new overhauling policies are gone. Business agility requires negotiation between business for prioritizing and agile project rollout.
  • Vision/Thought Leadership left to higher-ups only:  Challenging to staff to truly envision a change or target state not part of their incentive, even though best tactical ideas to enhance/meet strategy usually comes from within. Thinking gets bound up in current operational mire.
  • Revolving Door: Working to satisfy the management of today for organization political or self interest purposes. Middle management is often positioned or left to be soft with few exceptions on the drive needed to manage change. For example, with middle management and up are nearing or at retirement, large amounts started to retire, the churn caused by vacuum-effect at high level makes long term initiatives difficult to start or sustain.
  • Compliance Driven: Overwhelming amount of data calls with heavy-handed “fines”. Manage and plan to compliance – measuring to ineffectual measures
  • Compliance too complicated to understandCost/Price analysis on subcontractor costsSelf-monitoring/compliance reviews, manage contracting risks, methods and evidence used for estimation, understanding government acquisition regulations. Without expert help, small businesses are heavily limited to engaging.
  • Planning to the beast and not the customer: Fear at operational level of making decisions that lead to a innovative approaches or straying from norm – risk adverse. No reward for doing things better.
  • Delivering Value not part of Culture: Not sure of value of what we produce. no clarity on strategic outcomes and therefore have little recognition of recommended initiatives and what they mean to the workforce.
  • Blackbox Syndromes (aka Man behind the Curtain): Information Technology and management concepts and operations are overwhelmed by or shielded from the consumer of customer view. Programs/Mission are not informed of what IT has to do. Thus executive direction is disconnected, sometimes thus IT solutions or operations funding tie executives hands. Business agility gets put on backburner regardless of what Portfolio/Project Management is in place.
  • Surviving, not Thriving – Mission management model or system not designed to manage sustained change and transition. They are designed to deliver a product or service, if lucky.
  • Stovepiped Policy creates stovepipe programs: Cannot collaborate – need to get my task done now. Without collaboration, there is an inability for prioritization methods or techniques to be imparted and use effectively at all tiers of management.
  • Funding mismatch: Budget is a constraining variable in all work formulas precluding optimization across elements. These may be synthesied or aggrgated – mixed and matched as you see fit. Some programs may actually be funded right, but key functions of program budget are misaligned limiting what can be accomplished as a whole.
  • Enterprise Planning flavor of the day: Due to either past failures, or perception that new approaches are repackaged ways tried before kills internal buy-in towards integrated or collaborative techniques. Enterprise architecture, team functional/segment analysis, or agile project management may have been “tried” before, but instead of evaluating failure as tried to take on too much scope, other factors not resolved above, or simply, was over-engineered, are usually not labelled as the cause. The baby gets thrown out with the bath water or enterprise planning gets tossed aside due to lack of leadership, mistrust or burn-out.
  • Imbalance of Leadership Styles: Quick deciders, Stalling Stabilizers, Never-satisfied Challengers, Start-up Innovators – whatever the persona,  a lack of understanding of what each brings causes consternation or even over imbalance towards one style. Which leads to no decisions, status quo, low morale, or too much change.


IT Footprint Progression in the Federal Government… and the role of Architecture

Blog post
edited by
Matt Tricomi

In early December 2011, Xentity architects had a chance to discuss future progression with OMB current and former Chief Architects. The following captures some of the concepts discussed for architecture in context of the overall IT progression in Federal Government both looking back at where IT has been, but given current initiatives, but could be further emphasized, integrated, or uncovered moving forward.

PDF: ITProgression-Policy-Arch-Role.pdf

Where IT has been

Organization Information Role

IT originally was built as a Federated cost center. IT moved into Agency Data Centers model for archive/records. Commerce Models of economy drove eGov without migrating IT to Service models. Govt swamped in the T of IT, haven’t got back to the I. 

Trained Workforce

IT Acquisition originally was about financing/leasing federated shared manufactured systems Then Client/Server came, which is solution architecture, and 1000s of stacks came. Acquisition never got trained or linked with EA, and engineering mostly got outsourced

Data Center Footprint

Federated Regional Centers moved to Mission Centers moving to Server Rooms due to 1000s of system configurations. Initial FDCCI will close 1/3 of the portfolio count, but other 2/3s will have high transition costs

Technology Stack

IT stack started monolithic and slowly moved into server tiers then into service components. Though reduced individual system develop. cost, O&M Total Cost of Ownership was ignored and system security and interoperability was low.

Recommendations Discussed

Organization Information Role

– Institutionalized Funding for Enabling G2G IT Services at GSA
– Position G2C Services as High-Available Service Centers
– Focus Mission on Data Services training on Data Lifecycle that allows Private, NGO, Citizens to build on top of
– Increase EA role in support of mission and policy analysts for depth reach back to increase new political appointee effectiveness and limit turnover/ takeover disruption

Trained Workforce

– Position EA as depth knowledge base for acquisition guidance reachback
– Train all 3 workforce components on Performance maturity, Common Stack Architecture, and FEA/FSAM v2
– Establish CIO and EA relationship formerly with Acquisition
– Retire ineffective, existing burden to demonstrate credibility, eating own dog food, and increase success chances

Data Center Footprint

– Increase CMMI/ITIL Requirements to lower O&M
– Continue FDCCI
– Guide 2nd Consolidation Phase through taking advantage of CPIC renewal or new system cycles to assure re-use of new platform or data services in new shared platform environments to avoid simple hardware/system “cowpath” migration

Technology Stack

– Establish a Common Stack Architecture to be cloud managed service platforms by Select Large Agencies, waived Large Programs, and GSA
– Manage a True Common Stack Portfolio definition and implementation status
– Target New Solutions and Existing Systems for collaborative evaluation

 

 

 

 

 

 

 

Going International

Blog post
edited by
Wiki Admin

Expanding upon Xentity’s geospatial arechitectural services and eServices expertise, Xentity has gone international supporting the Indonesia NSDI effort. Xentity has recently supported partner Enterprise Planning Solutions, LLC on executing strategic and enterprise planning for the National Spatial Data Infrastructure effort in Indonesia.  

This very large program was looking to transform its NSDI program to be more effective and truly service-oriented in how it shares, develops, and invests in its geospatial program.

EnterprisePS called upon Xentity to support in envisioning the future service delivery model for true knowledge management. How can hundreds of organizations data not only be managed in a disciplined fashion to create information, but how can they train their users to best use that information to support their analysis, decision support, and other geospatial business intelligence concepts to their thousands of consumers.

Keeping in mind Indonesia is the 4th most populous country in the world with its 17,000 islands, ever changing shorelines, with high needs for volcanic and earthquake tracking and response, making information into knowledge quickly, accurately, adding the most value becomes extremely important.

Check out the BAKOSURNATAL Program’s web site (recommend using Chrome or another translation tool to translate the site).

Xentity leaders has previously provide enterprise architecture and translation services in Argentina in support of national financial Infrastructure modernization.