http://www.isaca.org/Knowledge-Center/cobit/cobit-focus/Pages/COBIT-Focus.aspx
viernes, 30 de agosto de 2013
jueves, 29 de agosto de 2013
EA Frameworks
http://www.cros-portal.eu/content/enterprise-architecture-frameworks
- Zachman Enterprise Architecture Framework (ZIFA)
- The Open Group Architecture Framework (TOGAF)
- Extended Enterprise Architecture Framework (E2AF)
- Enterprise Architecture Planning (EAP)
- Federal Enterprise Architecture Framework (FEAF)
- Treasury Enterprise Architecture Framework (TEAF)
- Integrated Architecture Framework (IAF)
- Joint Technical Architecture (JTA)
- Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) and DoD Architecture Framework (DoDAF)
- Department of Defense Technical Reference Model (DoD TRM)
- Technical Architecture Framework for Information Management (TAFIM)
- Computer Integrated Manufacturing Open System Architecture (CIMOSA)
- Purdue Enterprise Reference Architecture (PERA)
- Standards and Architecture for eGovernment Applications (SAGA)
- European Union—IDABC & European Interoperability Framework
- ISO/IEC 14252 (IEEE Std 1003.0)
- IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description
- Enterprise Service Oriented Architecture (eSOA)
- Commission Enterprise Architecture Framework (CEAF)
miércoles, 28 de agosto de 2013
martes, 27 de agosto de 2013
You Can’t Sell Unicorns
https://mail.google.com/mail/ca/u/0/?ui=2&shva=1#inbox
Many of my fellow business architects are incredibly excited about the value an architected approach to business design can offer. They believe in the model so strongly that the value is intuitively obvious. They believe so strongly, they expect the value to be intuitively obvious to everyone else. Unfortunately, it isn’t.
Even with all the excitement and promotion, business architecture remains a hard sell to business executives. A large part of the problem is that business architects (or more accurately, those who want to become business architects) are often presenting it as something it is not. They are making grand, but unsubstantiated claims about value creation, presenting business architecture as a magical panacea that can solve almost all business issues.
You can’t sell unicorns! Unicorns are mythical creatures first described around 398 BC. We all know what they look like even though we have never seen one. We know unicorns have magical powers that can prevent disease, heal wounds, and grant immortality even though we have never experienced it. Yes, business architecture is powerful stuff – but it isn’t magical. Here is a reality check on selling business architecture to your executives.
Business architecture is not a requirement. This is intuitively obvious but rarely acknowledged. Architects often believe in what they do so strongly they see it, not as an option, but as something that must be done. While it might be a great idea, it isn’t a requirement. Your company was able to start up, fend off competitors, and grow, all without any formal business architecture function. Businesses have survived for decades, some for a hundred years without the benefit of a business architect. Therefore, the question you should be asking yourself is “Exactly what is business architecture going to do for my organization that other functions have not? What problem or set of problems is it going to solve?” That’s what executives want to know.
Business architecture is not a best practice. As business architects, we like to think of business architecture as a best practice that every organization should utilize, but that isn’t really accurate. For something to be considered a best practice, it needs the following characteristics. First, it has to be something that is proven to work better than other known approaches. The operative word here is “proven”. Second, it must work consistently in a wide variety of contexts. If a practice has only been used successfully in a few instances then it may be considered a good practice or an innovative practice but without proven broad applicability, it is not yet a best practice.
Business architecture is a difficult product to sell. Products that are easy to sell have the following characteristics:
- They are easy to understand. They are tangible or easy to compare to other products of a similar nature.
- Other companies have proven the value. Business managers want validation from their peers.
- The cost is well defined. Managers have to budget for everything. They want to know the complete cost, not just the cost of the business architecture function.
- The outcome is predictable and easily measured. Just think a moment about the difficulties CIOs have measuring the impact of enterprise architecture and the impact that has had on EA’s growth.
Does this sound like business architecture to you?
The bottom line:_______________________________________________________________________________________________
Selling business architecture is considerably more difficult than most imagine. Yes, it is a great idea. Yes, it has great potential to solve complex business problems and aid in business design. Yes, every business could benefit in some way from a business architecture practice. But, it is also a mysterious, largely unproven product that your business managers have never seen.
Linking Business Strategy to Project Strategy
http://pmstudent.com/linking-business-strategy-to-project-strategy/
Business strategy is determined at the corporate level in a “deliberate” (i.e. planned) or “emergent” (i.e. reactive) response to the external business environment. The success of strategy is purely determined on how well it is executed. Projects serve as the vehicle to implement and execute the corporate strategy. Some firms are project-based organizations and recognize revenue by delivering on contractual projects. However, other firms may perform projects internally as a means to grow the company. In some cases, both situations may exist. Regardless of whether or not projects are internal or external, the alignment of the corporate initiatives with the project components is critical to the long-term position of the company.
The project manager is responsible for the scope, schedule, and budget (triple constraints) at the project level. A project is characterized in section 1.2.1 on page (5) of the Project Management Body of Knowledge (PMBOK Guide) third edition as a progressively elaborated temporary endeavor undertaken to create a unique product, service, or result. The purpose of corporate strategy is to sustain the business whereas the purpose of projects is to deliver objectives and then terminate. In section 1.6 of the PMBOK on page (16) the authors depict the project management context as follows:
“Project management exists in a broader context that includes program management, portfolio management and project management office. Frequently, there is a hierarchy of strategic plan, portfolio, program, project and subproject, in which a program consisting of several associated projects will contribute to the achievement of a strategic plan.”
The important take away from this extraction is the recognition of a hierarchy linking strategy to projects. Below is an illustration of the hierarchical linkage.
Figure 01
Projects are the vehicle used to execute strategic initiatives prompted by the “deliberate” or “emergent” efforts of the organization in an attempt to align the organizational components to the external environmental domains for sustainability. The organization may utilize programs as a means of grouping projects managed and controlled in a similar fashion as a means to achieve efficiencies and effectiveness of resources. On a more grandeur scale, programs and projects that are organized together to execute and deliver on strategic objectives is known as a portfolio. Portfolio management aligns projects and programs with operative goals and objectives which are known as the organizational strategy. Below is a simple illustration of the conceptual relationships previously presented.
Figure 02
Over the next couple of months, I will be conducting a series of five literature reviews. As the contextual analysis unfolds, the first review by Morris and Jamieson expands on the topic of moving strategy from the corporate level to the project level, which leads into the next review by Milosevic and Srivannaboon about a theoretical framework for alignment between these two levels. It is the third review by Johnson who analyzes the topic of drawing the gap closer between projects and strategy. In the fourth review, Breakthrough Performance Management produced an article about tying performance metrics to business strategy. The final review by Webber and Torti is at the individual level of the project manager doubling as client account executives. The compilations of articles critiqued and analyzed were selected to invoke a cognitive exploration of the events, conditions, or interrelationships between corporate strategy and project strategy.
If you want to read the full articles, see the references below for details.
Enterprise Architecture as Science?
Enterprise Architecture as Science?
http://rvsoapbox.blogspot.com.es/2013/08/enterprise-architecture-as-science.html
Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture. (Gartner website, retrieved 17 August 2013)
Business strategy
http://businesscasestudies.co.uk/business-theory/strategy/business-strategy.html#axzz2cayVMLsw
http://www.tutor2u.net/business/strategy/what_is_strategy.htm
What is Strategy
Author: Jim Riley Last updated: Sunday 23 September, 2012
Overall Definition:
Johnson and Scholes (Exploring Corporate Strategy) define strategy as follows:
"Strategy is the direction and scope of an organisation over the long-term: which achieves advantagefor the organisation through its configuration of resources within a challenging environment, to meet the needs of markets and to fulfil stakeholder expectations".
In other words, strategy is about:
* Where is the business trying to get to in the long-term (direction)
* Which markets should a business compete in and what kind of activities are involved in such markets? (markets; scope)
* How can the business perform better than the competition in those markets? (advantage)?
* What resources (skills, assets, finance, relationships, technical competence, facilities) are required in order to be able to compete? (resources)?
* What external, environmental factors affect the businesses' ability to compete? (environment)?
* What are the values and expectations of those who have power in and around the business? (stakeholders)
Strategy at Different Levels of a Business
Strategies exist at several levels in any organisation - ranging from the overall business (or group of businesses) through to individuals working in it.
Corporate Strategy - is concerned with the overall purpose and scope of the business to meet stakeholder expectations. This is a crucial level since it is heavily influenced by investors in the business and acts to guide strategic decision-making throughout the business. Corporate strategy is often stated explicitly in a "mission statement".
Business Unit Strategy - is concerned more with how a business competes successfully in a particular market. It concerns strategic decisions about choice of products, meeting needs of customers, gaining advantage over competitors, exploiting or creating new opportunities etc.
Operational Strategy - is concerned with how each part of the business is organised to deliver the corporate and business-unit level strategic direction. Operational strategy therefore focuses on issues of resources, processes, people etc.
How Strategy is Managed - Strategic Management
In its broadest sense, strategic management is about taking "strategic decisions" - decisions that answer the questions above.
In practice, a thorough strategic management process has three main components, shown in the figure below:
Strategic Analysis
This is all about the analysing the strength of businesses' position and understanding the important external factors that may influence that position. The process of Strategic Analysis can be assisted by a number of tools, including:
PEST Analysis - a technique for understanding the "environment" in which a business operates
Scenario Planning - a technique that builds various plausible views of possible futures for a business
Five Forces Analysis - a technique for identifying the forces which affect the level of competition in an industry
Market Segmentation - a technique which seeks to identify similarities and differences between groups of customers or users
Directional Policy Matrix - a technique which summarises the competitive strength of a businesses operations in specific markets
Competitor Analysis - a wide range of techniques and analysis that seeks to summarise a businesses' overall competitive position
Critical Success Factor Analysis - a technique to identify those areas in which a business must outperform the competition in order to succeed
SWOT Analysis - a useful summary technique for summarising the key issues arising from an assessment of a businesses "internal" position and "external" environmental influences.
Strategic Choice
This process involves understanding the nature of stakeholder expectations (the "ground rules"), identifying strategic options, and then evaluating and selecting strategic options.
Strategy Implementation
Often the hardest part. When a strategy has been analysed and selected, the task is then to translate it into organisational action.
Enterprise Architect / Solution Architect / MVNO / TOGAF
http://www.cv-library.co.uk/job/200195724/Enterprise-Architect-Solution-Architect-MVNO-TOGAF
Enterprise Architect / Solution Architect / MVNO / Portal
Berkshire
A leading telecommunications company is seeking an Enterprise Architect to join the business on a Permanent basis. This role is about ensuring the company delivers effective and efficient IT solutions and core services for the business to support the brand led strategy and Company Plan.
Key Responsibilities:
*Working within a small team of experts responsible for defining the architecture and governing the design & delivery of core IT solutions & services alongside the internal delivery capability, outsourced partners and key vendors
*To work closely with and leverage the expertise of other technical teams in CIO and the wider technology organisation to ensure compliance with architectural standards and principles, supporting the evolution of a consistent, integrated systems roadmap.
*To collaborate with the principle technical stakeholders & key business users to understand and to contribute to the business and technical strategy for IT Solutions and Enterprise systems.
*To understand the business roadmap within the relevant domains in order to provide governance of project design & delivery.
*Planning and management of technical run & maintain initiatives alongside business projects.
*To ensure that system designs produced by the design and development teams are fit for purpose and in line with our overall strategy.
*To ensure provision of solutions that are commensurate with required capacity, availability and performance of core IT solutions and services in terms of monitoring and capacity management.
*To provide assistance & guidance in the resolution of service issues related to core IT solutions and enterprise systems.
*To be able identify and articulate current business capability (people, process and technology), gaps and transitional steps to move between the two.
*To engage with the business stakeholders providing recommendations and solution shaping on the delivery options for projects providing a pragmatic balance between time, cost and quality whilst ensuring architecture adherence to the principles.
Skills Required:
*Experience with IT architecture, frameworks, integration technologies, design & solution implementation and operational transition.
*Comprehensive experience of industry standard development methodologies and techniques to deliver IT solutions.
*Broad experience of architecting complex integrated IT solutions in a Telecoms/ISP, Utilities, Pharmaceutical , Petrochemical or similar environment.
*Broad experience of integrating COTS products for Enterprise Systems into Billing, Revenue Management, CRM, Contact Centre, ERP, Supply Chain Logistics and Web/Mobile Portal domains
*Specific architectural experience of one or more the of the following will be an advantage:
*Provisioning platforms interfacing to Telecoms network platforms such as HLRs, HSS underpinned by a high level understanding of the core mobile network
*BPM & Order management
*Customer interfacing solutions such as Web Portals, IVRs, Mobile "Apps"
*MVNOs
*Demonstrable experience of successfully working with senior business users and influencing key stakeholders up to and including board members.
*Ability to build strong business relationships with both internal and external customers and vendors
If you are an Enterprise Architect interested in the above then please send an updated CV
Project People Ltd is acting as an Employment Agency in relation to this vacancy.
lunes, 26 de agosto de 2013
Business Architect - (Analysis, Process, Artifacts, TOGAF)
Location: --City of London
Salary: GBP75000 - GBP85000 per annum + Car Allowance, Bonus & Benefits
Business Architect - (Analysis, Process, Artifacts, TOGAF)
My financial client is seeking a Business Architect to work from their London head office, responsible for the development and maintenance of the business architecture.
You will be responsible for the analysis and assessment of the business’s capability requirements, business services architecture, business process models and application portfolio demands to support the business’s stated strategic aims. Responsible for the documentation and maintenance of the associated business architecture artefacts. In addition you will be responsible for the Shape business propositions – Investigate business demands and problems, seeking effective business solutions through improvements in automated and non-automated components of new or changed processes.
You will have a minimum of 5 years experience as a Business Architect with previous business analyst exposure, as well as having previous banking, finance or payments experience. You will also have previous experience of developing and maintaining the business architect and have the ability to liaise with all technology areas across the business.
Business Architect - (Analysis, Process, Artifacts, TOGAF)
Please check the job details, then fill in your details below and click "Submit now".
http://www.aplitrak.com/?adid=amVtbWEuNjI1OTAudHdpQHNjcmVjLmFwbGl0cmFrLmNvbQ
Certified ? You must be an Enterprise architect then..
http://sarinaviljoen.com/2013/08/21/certified-you-must-be-an-enterprise-architect-then/
I am often asked in my role as EA framework trainer, how to make sense of all the concepts presented in a framework and become a “real” practicing Enterprise Architect (EA). That set me thinking about my path to practicing EA and how theory alone, does not turn anyone into an Enterprise Architect.
Theory
One of the misconceptions I come across is that achieving certification or studying a formal EA framework, will remove all uncertainty about how to practice EA. This was not my experience. After I completed training, I was still uncertain about many concepts and how to apply them. I even started doubting many of the things I felt very sure about before I encountered the formal EA framework.
But after some time and consideration, I realized that the framework merely provides the skeleton on which to hang all the loose ideas and concepts I was exposed to and enables a structured way of understanding the bigger picture. I experienced the framework concepts challenging me to think about things in a different way – proposing new things I did not consider before.
In addition, I became more confident – since my understanding of what needed to be done and why, was based on solid foundations. My arguments were backed up by some heavyweight practitioners and they provided the support in the theory when I needed it.
Practice
“In theory, theory and practice are the same. In practice, they are not.” – A Einstein
Practicing EA in the real world however is the key to becoming a practicing architect. Here where concepts become tangible; stakeholders become individuals and uncertainties and myths have a way of presenting themselves in a very real and diverse way, is where the learning takes place and the skill is honed. Only once I practiced, and practiced some more, did I gain the insight to distinguish where to apply one concept versus another, did I grasp the theory and adapted it to my own particular flavor. Did I start to contribute to the design of this discipline to be significant and valuable in the future.
Theory and Practice
The theory of Enterprise Architecture describes the practice and discipline as it is documented in its current form. It is my recommendation to be skilled in the theory. I certainly lacked confidence without the framework theory to guide me and I suspect so does many other EA’s.
My advice is to combine EA Framework theory and practical Enterprise Architecture experience to become a well-rounded EA. My journey started as a practitioner and then only was I exposed to a formal framework. So whether you start with the theory or you start by practicing; both is required for a rounded Enterprise Architecture Practitioner. What is or was your path to EA?
lunes, 19 de agosto de 2013
domingo, 18 de agosto de 2013
sábado, 17 de agosto de 2013
A framework that can illustrate capabilities and business services
A framework that can illustrate capabilities and business services
A framework that can illustrate capabilities and business services
viernes, 16 de agosto de 2013
BA in STA group
Home > What is Business Architecture?
The following infographic illustrates common disconnects in today’s business environment and shows how Business Architecture serves to properly align the organization. Business Architecture reveals how an organization is structured and can clearly demonstrate how elements such as capabilities, processes,organization and information fit together. The relationships among the elements dictate and specify what the organization does, and what it needs to do to meet its common goals. A PDF version of the following infographic is also available for download.
Consider the following topics:
- What is Business Architecture?
- Why is Business Architecture valuable?
- How can Business Architecture be used?
- When is a good time to engage in Business Architecture?
- Where can I learn more about Business Architecture?
Whatis Business Architecture?
STA Business Architecture bridges the gap between a company's strategy and its successful execution. We work with you to understand where your business really is, where it wants to go, and what it truly takes to get there - without the costly risk of trial-by-error. We integrate deeply into your organization to address all dimensions of your challenges and identify the best path to resolution and subsequent realization of strategic goals.
70% failure rate: corporate change management initiatives.
Source: "Do 70% of All Organizational Change Initiatives Really Fail?" Mark Hughes, Journal of Change Management, Dec. 2011
10% success rate: companies that execute on their vision.
Source: From statistics compiled by Robert S. Kaplan and David P. Norton, cited inExecutive Strategy with the Balanced Scorecard
"To help merge technology and business processes, a new breed of enterprise architect - known as the business architect - is emerging."
Whyis Business Architecture valuable?
Does your company suffer from chronic disconnect?
A common problem in today's business: the upstream corporate vision fails to get successfully translated into actionable objectives. Downstream, critical coordination fails amongst business units, as well as between the business and IT.
Missing the target
When individual business units interpret the strategy differently, a "mutually agreed upon" hybrid solution results that is inefficient, non-integrated - or worse - misses the target objectives entirely.
Uncovering misalignment
Business Architecture reveals where organizational investment is not well aligned to the strategies.
Business Architecture aligns the organization
Business Architecture serves to properly align the organization. Business Architecture reveals how an organization is structured and can clearly demonstrate how elements such as capabilities, processes, organization and information fit together.
Lingua franca: facilitating change through a common language
We deliver a reusable set of assets - in a commonly understood language - that enables your company to quickly assess and make strategic or operational changes.
Delivering business transformation
We ensure successful strategy translation by enabling your company to visualize its business strategy end-state before the plan is implemented. Our Business Architecture approach delivers:
Focused and aligned strategy
Improved decision making
Increased operational efficiency and capacity for growth
Agility in your business and IT execution
Howcan Business Architecture be used?
How value is derived through Business Architecture
Any business - from an entrepreneur to the largest corporation - can benefit from Business Architecture. Here are a few examples of how we have helped organizations to apply Business Architecture:
Start a new company
Define a new market
Define a new product offering in the marketplace
Restructure a business unit
Drive legacy modernization
Reinvent what and who a company is
Integrate people, processes, capabilities, technology and culture during M&A
Transform a Fortune 50 enterprise around customer experience
Make a decision that dramatically reshapes a federal program
Solve social problems holistcally
Whenis a good time to engage in Business Architecture?
Engage Business Architecture at the beginning of a corporate initiative
If your organization has not applied Business Architecture before, select an appropriate effort to pilot the approach to help build an understand of how it applies to your organization and foster buy-in. Our Business Architecture Practice offers the following services available to meet your specific Business Architecture needs:
Business Transformation Enablement
New Business / Product / Market Support
Large-scale Technology Implementation Support
Compliance Management Support
Mergers and Acquisition (M&A) Support
Engage us to help start your own Business Architecture practice
Let us help you start your new Business Architecture practice, from defining your value proposition to standing up all the necessary components of your internal practice. We offer training and mentoring to develop your staff into highly trained business architects. We provide the following services to leverage, create, or enhance your own Business Architecture Practice:
Practice Evaluation and Strategy
Practice Structure and Role Development
Architecture Change Management and Communication
Enterprise Model Building
Standards and Method Development
Governance Processes
Practice Metrics and Evaluation
Tool Assessment and Alignment
Training and Mentoring
Business Architecture Community Support
Wherecan I learn more about Business Architecture?
Contact us today
Talk to us today to learn how STA Group's Business Architecture Practice can work for you.
jueves, 8 de agosto de 2013
miércoles, 7 de agosto de 2013
Does anyone really understand the TOGAF concept of "building blocks"?
nterestingly, I just received an e-mail circulated by one of the
guys in the TOGAF forum working on the Ontology for SOA. He too
(a very active TOGAF forum member) raised a discussion on the
definition of a building block.
Sometimes its these terms we have all been bandying about for
years that are hardest to agree the definition of.
Part of his proposed definition went as follows:
"A Building Block is an abstraction of a component of a system
(where "system" and "component" are as defined in IEEE 1471)."
He went on to explain, "When an architect is developing an
architecture, he or she does not work with real components, but
works rather with descriptions of idealised components, called
building blocks. For example (to extend an example that will be
familiar to the SOA Ontology team), Joe is planning to build an
automatic car wash. He does not just go out and buy a plot of
land and order a car wash machine, and hope that when the
machine arrives it will fit on the plot of land that he has
bought in a way that allows people to drive in and use it
easily. Instead, he draws plans on paper showing the plot of
land and the position of the car wash machine on it, with
entrance and exit routes, payment kiosk, etc. He is working
with a set of architecture Building Blocks, which include "plot
of land" and "car wash machine".
This prompted me to pose the following observations / questions
back to the forum members:
"You could be talking about a pattern, or indeed a reference
model. You also mentioned the confusion between building blocks
and components.
I couldn't help wondering if there is a hierarchy of
- components
- that together make up building blocks,
- that together make up patterns,
- that together make up a reference model.
All are, as you say, abstract representations of the real
components, building blocks etc."
It would be interesting to hear your thoughts...
Popular White Paper On This Topic
0
Jayant Dani replied Jan 19, 2011
It is true in sense of understanding , currently I am working creating a ABB and SBB for the few Reusable blocks, Now I like create new term called Reusable Block (RB).
ABB and SBB of the TOGAF defination has lots of gray area which can be interpreted from code snippnet to EAS. But do not give any clarity what we are looking for, In your case explained , I will say that
CAR is Reusable block with following item
a. ABB for CAR which specified the Car as external specification and services should have,
b, SBB for Car which is detail technical specification like engine type, capacity etc
c. Actual solution -- Ex. Toyata camry, ford Punto etc,
In typical sense , Archiects or solution desinger is looking for Ford Punto but he is talking about mix of ABB and SBB as block and get round and round,
We need to creatre a RB such that there is
one ABB,
one SBB
and Multiple implementation SBB it really become Building Block.
Cheers
Jayant Dani
Solution Archiect , Togaf Certified,
0
Marc Mc Rae replied Jan 19, 2011
I too would be interested in a lot more information around TOGAF & EA
(Enterprise Architecture) especially things like templates, tools, checklists, example models, etc.
Where does this terminology (RB, ABB, SBB) originate from?
What's the context (view-point) of this?
Are you using any UML tools..?
Archimate has tried very hard to set some UML standards.
UML is currently the most important industry-standard language,
for specifying, visualising, constructing, & documenting artefacts of
systems. There is a tendency to stick to roughly 3 models;
- structure diagrams - called package diagrams
- behaviour diagrams - called Use-case diagrams, state or sequence diagrams,
even communication
- implementation diagrams - component & deployment diagrams
Sorry I'm just sharing my thoughts here...
Marc Mc Rae
Enterprise Infrastructure & Solutions Architect
0
Jayant Dani replied Jan 19, 2011
No issue , It is really more fluid concept if go through the definition of ABB, SBB in
TOGAF documents. But when start working on it defining same in exact artifacts
will be become more difficult.
Actually ABB and SBB ask us think even smallest part of solution as a architecture in complete . That gives us more freedom of thoughts in sense of overall architecture.
In my experience I found that I can architect any solution which by definition 100% scalable while
Explaining SBB , I will start adding constraints due to available choice of algorithm and technology but it will be in attribute format for that SBB.
In actual solution , it will publish respective number for those.
Now answer to another question ABB and SB are terminology used by TOGAF for defining Isolatable building block of Enterprize architecture. It is exactly taken from Civil engineering concepts like Brick , wall , slab etc which are nothing but building blocks for architecture.
RB is special case ABB and SBB , we like to bring in our organization, Where RB means for reusable Archiecture plus solution building block with actual implementation.
Answer to third question, ABB and SBB artifacts need to defined very well. We can use tool like RSA to define ABB and SBB upto good extent.
Hope I am able to provide some clarification to your question.
Cheers
Jayant Dani
Solution Archiect
Enterprise Architecture, TOGAF and Solution Architects
Enterprise Architecture, TOGAF and Solution Architects
http://sergethorn.blogspot.com.es/2009/09/enterprise-architecture-togaf-and.html
Building Block – A (potentially re-usable) component of business, IT or architectural capability
- Architecture Building Block (ABB)
o A constituent of the architecture model that describes a single aspect of the overall model
o Describe required capability
o Shape the specification of SBBs
- Solutions Building Block (SBB)
o Represents components that will be used to implement the required capability
o A candidate physical solution for an Architecture Building Block (ABB); e.g., a Commercial Off-The-Shelf (COTS) package that is a component of the Acquirer view of the architecture
All ABBs will be stored in the Architecture Landscape of the Architecture Repository. These ABBs will have different levels of granularity to suit different architectural objectives.
The Architecture Definition Document which describes an architecture will contain all artifacts describing as views the building blocks.
During the Phase E, Opportunities and Solutions, we identify work packages and group them into projects, consolidate the gap analysis results from phases B to D, identify the building blocks to be developed or acquired reusing the existing ones (stored in the Architecture Repository) as much as we can. From there, we identify the SBBs which could potentially address one or more gaps and their associated ABBs. Existing SBBs have obviously also to be considered taking the interoperability requirements and dependencies into consideration.
The Solution Architect has a key role in this phase as (s)he will probably be the best qualified to identify the appropriate SBBs. He or she participates in the definition of any Transition Architectures, identifies potential solutions, and helps to formulate a high-level implementation and migration strategy.
During the Migration Planning phase they also have an important mission to ensure that SBBs are properly designed or that acquired solutions support business requirements. The Solution Architect may work closely with the vendor if a COTS solution is considered. A solution includes the hardware, software, and supporting people and documentation to solve a problem.
“The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments.”
Source: TOGAF 9 (15.4.1)
When the Implementation Governance phase is started, the Solution Architect will work in partnership with the procurer/acquirer in addition to the development team and/or the vendor. He will ensure that the development will comply with the target architecture.
When the solution building blocks are developed or integrated with other existing solutions, the Solution Architect will be working with the development team. His role will be to contribute to the design, development, integration and testing of the new components. This may be considered as being the Solution Architecture activity.
A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high level business and/or IT system specifications and a portfolio of implementation tasks.
Solution architecture starts with an understanding of the problem, which should be documented in the business scenario, and this is where so many projects fail. Too many people have the idea that solving a problem is all about coding.
The Solution Architect is a member of the Enterprise Architecture team but becomes at a later stage also a member of the Development team. His role is mixed; he is the bridge between concepts and implementation. However, the Solution Architect does not operate at the Strategic Architecture level (at the level of the Enterprise) but mostly at Segment and Capability Architecture levels.
“The Solution Architect has the responsibility for architectural design and documentation
at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.”
Source TOGAF9 (52.6.3)
There is no mapping for a Solution Architect in the TOGAF Skills Framework, but I would suggest, based on my experience, the following proficiency levels:
TOGAF proficiency levels:
Source TOGAF9 (52.4.4)
This approach is related to the current situation in the market for Solutions Architects, where we see that most of their activities are limited to phases E to G. Another approach would be to consider a Solution Architect being involved in all phases of the TOGAF ADM from phase A and on-wards. A follow-up paper will describe how to address solutions from Phase A , when constraints exist, defining the role and responsibilities of a Solution Architect.
martes, 6 de agosto de 2013
EA is Dead
http://simplicable.com/new/enterprise-architecture-is-dead?goback=%2Egde_67926_member_259146987
Joke of Architecture: TOGAF deals with Enterprise Architecture
lunes, 5 de agosto de 2013
viernes, 2 de agosto de 2013
Modelos de Negocio
http://francoitgrc.wordpress.com/2013/07/30/modelos-de-negocio/
“¿Tienes espíritu emprendedor? ¿Piensas constantemente en cómo crear valor y construir nuevas empresas o en cómo mejorar o transformar tu empresa? ¿Buscas formas innovadoras de hacer negocios para dejar atrás los modelos anticuados?”
Con esas preguntas desafiantes comienza uno de los libros imprescindibles sobre Modelos de Negocio, en una era donde lo único constante es el cambio y donde los casos resonantes de empresas anteriormente líderes e imbatibles en su segmento (Kodak, Nokia, etc) nos demuestran la necesidad de contar con un “Modelo de Negocio” validado o transformado.
“Generación de Modelos de Negocio” (Alexander Osterwalder e Yves Pigneur) Ed. Deusto:
Este libro se autodescribe como “Una guía práctica para visionarios, revolucionarios y retadores que quieran desafiar los anticuados modelos de negocio y diseñar las empresas del futuro” y es una excelente colección de herramientas y técnicas, tales como:
- Lienzo: es donde plasmamos toda nuestra creatividad en forma visual. Es una herramienta sumamente práctica y visual para describir, analizar y diseñar modelos de negocio. El libro incluye los ejemplos de lienzos de empresas como Apple, Google, Amazon, etc
- Patrones: este apartado nos brinda patrones de modelos de negocio basados en conceptos de grandes pensadores empresariales, por ejemplo: “The long tail” (ej.: LEGO), “Gratis” (ej. Skype), “Plataformas multilaterales” (ej. consolas Nintendo), etc
- Diseño: técnicas para el diseño de modelos de negocio, tales como: aportaciones de clientes, ideación, pensamiento visual, creación de prototipos, escenarios, etc. Dentro de esta sección, se destaca especialmente la herramienta “Mapa de Empatía”, útil para analizar la perspectiva del cliente (¿Qué piensa y siente?, ¿Qué ve?, ¿Qué oye?, ¿Qué dice y hace?, sus esfuerzos y resultados)
- Estrategia: vista a través de la lente del modelo de negocio. Cómo reinterpretar la estrategia para cuestionar constructivamente los modelos de negocio establecidos, incluyendo una perspectiva sobre la estrategia del océano azul (otro excelente libro que justificaría su propio post).
- Proceso: esta sección nos trae un proceso genérico para el diseño de modelos de negocio innovadores que reúne todos los conceptos, técnicas y herramientas descriptas en el libro.
Más allá de que este libro se encuentre orientado especialmente hacia quienes deben definir, validar y/o transformar los modelos de negocio de las organizaciones, puede ser útil también para aquellos profesionales involucrados en el IT Governance/Management, dado que:
- ¿acaso puede estar sincronizado estratégicamente TI con un modelo de negocio que no comprende?
- ¿puede reaccionar ágilmente TI en la era del cambio, cuando el modelo de negocio de nuestra organización se va transformando cada vez más rápido?
- ¿desde las áreas de TI conocemos suficientemente a nuestros clientes como para brindar soluciones orientadas a sus necesidades?
- ¿desde la Dirección, se ocupan de que el Modelo de Negocio adoptado sea conocido por toda la organización?
En conclusión, una lectura sumamente interesante, plena de herramientas prácticas, conceptos innovadores y ejemplos concretos.
ISACA Conference - COBIT 5: IT is Complicated, IT Governance
http://www.youtube.com/watch?v=p0N7PipNAeE&feature=youtu.be
COBIT 5 - The Next Evolution (Global Knowledge webinar)
Suscribirse a:
Entradas (Atom)