SEAS Inc. and OAGi in formal Collaboration Talks
Feb27

SEAS Inc. and OAGi in formal Collaboration Talks

SEAS has formally engaged with the Open Applications Group Inc. (http://www.oagi.org/) in collaboartion discussions for joint research in the areas of Integration and Service Oriented Architecture (SOA). The discussions center around 2 main areas: 1) Offering thought leadership and access to research of both organizations to members of SEAS and OAGi 2) Leveraging SEAS’ Case Study platform and method to conduct R&D for a real-world case study that articulates the business value of Integration and SOA. About OAGi: The Open Applications Group is a 501(c)(6) not-for-profit open standards development organization. Founded in 1994, The Open Applications Group Inc. (the OAGi) is organized to promote business process interoperability for both inter & intra enterprise business processes and to encourage the creation of and/or create and endorse one or more standards to assist organizations in achieving connectivity and multiple-source integration of inter & intra enterprise business processes.visit OAGi:...

Read More
ABM Case Study Situational Analysis Update
Dec09

ABM Case Study Situational Analysis Update

The SEAS’ Consulting team participating in the ABM Health Check Engagement Simulation completed its Situation Analysis phase.  The team worked diligently across the three streams of Strategy & Innovation, Enterprise Architecture, and Change Management to examine, analyze, collate, and document its findings. The team used Kepner-Tregoe’s Situation Analysis (SA) method to complete the analysis of all issues and enumerated 53 major issues which translated into 73 clarified concerns.  The 73 concerns were further rationalized (eliminating redundancies and consolidating issues with single action to resolve) into 51 specific and prioritized concerns classified by priority, importance, & growth.  Each of the individual streams: Innovation & Strategy, Enterprise Architecture, and Change Management were pegged against these 51 concerns specifying which stream, or practice, leads the resolution of the concern and which streams, or practices, receive the analysis to complete its downstream work. As an example, one of the 51 specific concerns was: “Production Schedules/Forecasts are not used during sales cycle for new commitments.” This concern was prioritized as Seriousness (H), Urgency (H), Growth Trend (Increasing).  It was then assigned to  Business Architecture (EA) to lead its resolution.  The output of this effort will feed the Change Management team to work on the People aspect of resolving this concern such as Training & Communication.  Finally Technology Architecture (EA) will be the recipient of the output from Business Architecture & Change Management team to define the target Architecture for addressing this concern. In the coming few weeks the three streams will complete their analysis of the top concerns and develop the associated roadmaps.  Once that phase completes the consulting team will work on consolidating the deliverables into one body of work that rationalizes the analysis and proposes one roadmap as an output of the Health Check engagement. The consulting team will be posting their individual updates in the coming week to share with the society their findings and experience thus far with the case study. Stay tuned for progress as we continue our journey in solving ABM’s Business...

Read More
5 Capability Model – Governance by Design
Nov21

5 Capability Model – Governance by Design

5 Capability Model Introduction to corporate governance and IT governance using a 5 capability model. Management capabilities Party management capabilities Offer management capabilities Financial management capabilities Transactional capabilities Expense transaction capabilities MIKE2.0 Investment & Planning September 2013 content award and inclusion under Creative Commons copyright Revenue transaction capabilities The five capability model provides the zero data loss scope for any organization or agency, the recovery time objectives for zero downtime and zero data loss.  The same five capabilities allows the financial scope in service management for full regression and Sarbanes Oxley.  Nearly all of the activities are universal across industries and geographies.   Who cares about this issue? The external stakeholders who are alert and using the audit reports and risk register as key indicators of the organizations operating practices.   There are some technical leaders who are happy to build a healthy risk register as it justifies the need for their teams. The executives and management would ideally want to have the rule without unnecessary risk,  if they are aware that basic business management systems were abandoned with the collaborative leadership models. Question for an executive sponsor You are an employer who must supply tools to allow the employees to perform the task they were hired to perform. “If the tools fail, is the employee at fault or the employer who supplied faulty tools?” Question for an employee If I am hired to perform a task and the tools are allowing me to break policies or avoid procedures.  “Am I expected to know how and when policies apply to me and my role if the applications were changed from doing this for me?” Yes, is there any reasonable expectation of success?  No, neither an employer nor an employee are setup for success. How do I address such a disconnect? Enable the rule Allow a certain degree of variance Expect an exception path Many of us are immediately sent a mental message that the term “governance by design” either hurts and constrains our stakeholders or it prevents innovation. Key driver in this approach is to enable the possibility. What if the possibility enables innovation by design? What if you also gain a way to change without slowing down your core business? What if you reduce complexity and increase agility and speed? Imagine if we got out of the weeds when we govern the enterprise? It’s about carving out the minimum viable systems and measuring at the leverage points. Segmentation Tomorrow, we will have policy based access and far fewer chances to introduce risk. Three operating models aligned to the customer market behaviors. Run your business Change your business Innovate to grow your business Ideally, using...

Read More
Leveraging Enterprise Architecture in Enterprise Risk Management
Nov21

Leveraging Enterprise Architecture in Enterprise Risk Management

Enterprise risk management (ERM) is one area that I believe EAs could positively contribute to. Several years back, a manager in charge of ERM approached me enquiring how EA could benefit his department. He knew what EA was and was keen to see if he could benefit from it. His primary challenge was assessing impact of risk across the enterprise; his team was handicapped, as they did not have traceability capability. In this article, I explain how EA helped him achieve his objectives. Organizations deal with different types of risks that, if not attended to, could have adverse impact on organization performance and outcomes. Generally speaking, “risk” is the potential of undesirable outcome resulting from a given action or omission (foreseen or unforeseen). On a different note, “risk management” (RM) is the identification, assessment, and prioritization of risks followed by appropriate actions to minimize, monitor, and control the risk impact. The intention of this blog is not to explore risk management as such but rather explain how enterprise architecture (EA) could benefit risk management. Those of you seeking more details about risk management can explore other external sources. While I do not dispute that RM is not unique to EA, it is important we appreciate that EA has great potential to contribute to GRC (governance, risk and compliance) by feeding into the enterprise risks management (ERM) process. The problem with traditional RM efforts like program and project (risk management) that are usually independent, narrowly focused and functionally driven is that they work in silo and fail to integrate at enterprise level leading to fragmented view of risks each with its own classification, criteria, and measure. Ultimately, most critical risks with major business impact never make it at the enterprise level though the resulting consequences do. So what is the rationale behind leveraging EA in ERM? As we all know, EA involves blueprinting an enterprise by connecting the business, information, application, and technology layers. Usually, we achieve this iteratively through an architecture development method like TOGAF. Whenever we create (or update) and link each of these architectural layers, we get the opportunity to assess impact of change on subsequent layers. The presence of this unique traceability creates a window of opportunity for ERM. If we extend the concept further, it could help organizations identify and assess impact of risk on these architectural layers (I like to view this as enterprise assets). Why do I say so? One of the toughest challenge in ERM is modeling risk and its impact on enterprise assets. Techniques like fault tree and event tree analysis have been used to model risks before but unfortunately, they are ineffective when...

Read More
Change Management – Purpose and Perspectives
Nov21

Change Management – Purpose and Perspectives

Change Management We have two distinct types of Change one for IT and one that is a more structured time intensive process for people and process changes.   There are times when these two processes are misunderstood and IT takes on the business change without taking the action.  The results are issues caused by an IT change.  Nuances or a quick fix in the Data Warehouse, looks like the solution to the problem, when in fact the process and people are fumbling while a report looks great.  Missing the change management for people has become a common problem for many companies. Business Change Management IT Change Management Business – Any change to people, process or technology. The people change management requires people, may include technology and may also include process, these changes are typically performed by specialized resources “Change Management” experts.  Managers of the people who need to change and change management experts are partnered for the change and work through the people parts of change in effective change programs. A business change that requires people to make adjustments to the way they perform their work, activities or process. May be prompted by a re-organization May be prompted by an acquisition May be prompted by transformation May be prompted by an audit and managed through strategy May be a change in strategy May be a change in technology An IT service management Change Release – IT change has been crafted for non-release or no data type changes Planned Maintenance Data migration – non-structure data migration 1:1 mapping Backend db performance tuning Change Management – People A scheduled release planned or in some cases not IT related and simply aligned to a release for managing the gate criteria for the people changes. Dependencies in a release Any changes to the five capability model requires “Full integration and regression testing” a reason most project teams mark “no” sox and no regression testing or no dependencies in a release A recovery time test (ideally item 2 and 3 are sequenced in a way to incorporate sarbanes-oxley testing). The changes which occur in any business function have downstream impacts when the change relates to the five capabilities.  A business process architecture allows greater visibility into the inputs and outputs for greater understanding and visibility. This is true in an integrated organization, where people are sharing the information for lower waste and greater efficiency.  At least, in an organizations where the information is integrated across business functions requires change management. The primary point for us to consider, when we think of a change and it involves people, process or technology we are talking about a concentrated communication strategy...

Read More
Decision Support Enterprise Architecture
Nov11

Decision Support Enterprise Architecture

 Enterprise Architecture is a framework of decision making through its models/view which are the integral part of EA discipline. The EA models/views should be relevant to the management deicions making needs and thus they should be designed based on the suitable metamodels. These metamodels, in turn need to be properly and continuously maintained. While there exits several methods for the metamodel development and matinetanance, these typically focus on internal metamodel qualities and model engineering processes, rather than on the actual decision making needs and their impact on the metamodels used. These metamodels, in turn need to be properly and continuously maintained. While there exists several methods for the metamodel development and matinetanance, these typically focus on internal metamodel qualities and model engineering processes, rather than on the actual decision making needs and their impact on the metamodels used. From previous many years, Enterprise Architecture (EA) has grown into an established approach for management of information systems in enterprises. EA is a model-based in the sense that diagrammatic descriptions of the systems and their environment, constitute the core of the approach. The purpose of EA models/views is to increase the general understanding of an organization’s business along with its information system landscape, the objective is to make corporate decision making easy and responsive. The backbone of any EA model is its metamodel, the design and structure of this metamodel greatly affects the way organization prepare its decision reports. The metamodel has to be interoperable and traceable, to get the optimum value out of it. There are few popular frameworks which propose a metamodel of their own e.g Defence Framework(DoDAF) and MODAF, while some have focus on development and maintenance processes which can be applicable to many metamodels such as FEA and TOGAF. In any case, regardless of implicit or explicit frameworks, metamodels play an important role in overall EA efforts. For any EA model to gain success, the metamodel for it must support decision making for the business and IT of the organization. An overly done metamodel will complicate its maintenance and very simplistic metamodel will kill the purpose of EA. A middle approach is required when designing, so that it fits the purpose for the organization. To keep a metamodel align with business needs, the information prescribed by the metamodel must be relevant to management decision. Business expects a tangible value from the EA effort and  business , to some extent is interested in how there organization is operating holistically and in integrated form but what they are mostly interested in is, what decisions they should make to enhance the productivity of the operating structure. Some of the crucial areas...

Read More