lunes, 31 de marzo de 2014
sábado, 29 de marzo de 2014
jueves, 27 de marzo de 2014
martes, 25 de marzo de 2014
domingo, 23 de marzo de 2014
sábado, 22 de marzo de 2014
jueves, 20 de marzo de 2014
miércoles, 19 de marzo de 2014
martes, 18 de marzo de 2014
Enterprise Architecture Aligns with Business Strategy
By 2016, 30 percent of enterprise architecture programs will be collaborations between business and IT, revealing a fundamental shift in IT, says new Gartner research. This is an increase from 9 percent in early 2011.
EA, traditionally an IT practice, has been evolving for several years to become aligned with business strategy. Several trends have inspired the evolution, including business users making technology decisions, increased management pressure on EA to demonstrate business value and continued emergence of new disciplines to enhance collaboration.
“It’s no longer about IT for IT’s sake, or EA for EA’s sake, but about how EA is enabling the business to run, grow and transform,” says Betsy Burton, vice president and distinguished analyst, Gartner. “Right now those who are still focused on IT are in the minority.”
“Enterprise architects have woken up to the fact that a collaborative relationship with the business is essential to their success. These things aren’t independent, they’re interdependent,” says Philip Allega, research vice president at Gartner. “Enterprise architects are lifting their heads out of the work of creating deliverables in EA to think about ‘consumability’ and the results of that consumption on the organization’s future.”
More information is available in Gartner’s report "Beyond the Tipping Point: EA is Strategic."
Enterprise architecture and business architecture
At the Melbourne BA conference I was asked to sit on a panel discussing what the differences and similarities of these two roles are. I am not an architect and have not been one in anyprevious career. So I wan't neccessarily prepared, and left that dscussion a little disapointed with where it went.
The discussion itself got stuck on how the Zachman framework is a full architectural framework that gos beyond technology. Yep. Okay, what next?
I'll throw up a few of my (still unprepared) thoughts here and see what comments I get.
- Architecture is about designing in future capability, not delivering it
- The differnece between enterprise architecture and business architecture is only a matter of terminology. Or is it? Mabe the business architure is less focused on the technical?
- If you put up an architecture it becomes the baseline for change, and variations from it have to be justified (to some degree)
- This means archicture should be an ongoing role and should generallly be flexible and open enough to accomodate new ideas
- Like anything, context matters a lot
- BAs are great candidates for architecture roles as they evolve through technology and business design
- Why doens't architecture drive more business cases?
lunes, 17 de marzo de 2014
Frequently Asked Questions about TOGAF
http://blog.firebrandtraining.co.uk/2014/01/faq-togaf.html
What is TOGAF?
TOGAF is a proven enterprise architecture methodology and framework used by the world's leading organisations to improve business efficiency. It’s the most prominent and reliable enterprise architecture standard, ensuring consistent standards, methods, and communication among enterprise architecture professionals.
What is an architecture?
By definition, an architecture is “the fundamental organisation of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”. However, TOGAF does not strictly adhere to this definition. Depending upon its contextual usage architecture has two meanings in TOGAF:
- A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
- The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.
Why do I need an IT architecture?
The primary reason for developing an architecture is that it provides the technical foundation for an effective IT strategy, which is the core of any successful modern business strategy.
Today’s executives know that the effective management and exploitation of information through IT is the key to business success, and the indispensable means to achieving competitive advantage. An IT architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.
Furthermore, a good IT architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it assures the needs of the organisation for an integrated IT strategy, permitting the closest possible synergy across the extended enterprise.
Why do I need a “Framework” for IT architecture?
Using an architectural framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business.
TOGAF plays an important role in helping to ease the architecture development process, enabling IT users to build genuinely open systems-based solutions to their business needs.
Who would benefit from using TOGAF?
Any organisation undertaking, or planning to undertake, the implementation of an enterprise-wide technical infrastructure for the support of mission-critical business applications, using open systems building blocks.
Customers who design and implement corporate architectures using TOGAF are ensured of a design and a procurement specification that will greatly facilitate open systems implementation, and will enable the benefits of open systems to accrue to their organisations with reduced risk.
What will my TOGAF credentials give me?
Enterprise architecture professionals fluent in TOGAF standards enjoy greater industry credibility, job effectiveness, and career opportunities. TOGAF helps practitioners avoid being locked into proprietary methods, utilise resources more efficiently and effectively, and realise a greater return on investment.
If you haven’t found the answer to your question, visit TheOpen Group’s FAQ site.
Roadmaps in Enterprise Architecture: An Introduction
http://info.corso3.com/blog/bid/338702/Roadmaps-in-Enterprise-Architecture-An-Introduction
Every organization we’re talking to right now is, at some level, managing roadmap initiatives.
We’ve seen countless organizations using Microsoft PowerPoint or Excel vying for continuity but struggling with maintenance and preservation. It’s been apparent for a while that roadmaps are an important viewpoint for various stakeholders in an organization; and the industry is slowly realizing that Roadmapping applies to both the business world and the IT world.
Why are roadmaps important?
Roadmaps are visuals that represent the future vision of facets of a business and/or its IT components. Roadmaps are an important concept when we look at planning. Whether that's planning out our applications, business capabilities, processes or technology for any one of a number of reasons including:
- Supplier Management
- Application Portfolio Management
- Technology Consolidation
- Mergers and Acquisitions
Is Enterprise Architecture important?
Enterprise Architecture (EA) techniques provide a set of views that correspond to the business and IT infrastructure. EA provides the visuals (including Roadmaps) that allow a company to see where they are today and where they want to be in the future. ArchiMate® and TOGAF® are such enterprise architecture techniques.
Most business and IT stakeholders don’t even need to have an understanding of ArchiMate® or TOGAF® to analyse a roadmap that is produced by Enterprise Architecture. Enterprise Architecture is important however as it allows us to build roadmaps in a formal and structured manner. It enables us to roadmap in a repeatable fashion that is cost efficient, and blankets the entire business.
Roadmaps come in a number of forms including:
- Strategic roadmaps
- Lifecycle roadmaps
- Technology and application roadmaps
These points are usually presented to stakeholders in PowerPoint or Excel. The people that manage these roadmaps will tell you what a chore it is to maintain them as the business changes. They often become stale and out of date and are seldom revisited.
To achieve a fully functioning roadmap, you need to embrace and automate your roadmap delivery. You still need to use the Microsoft Office tools to visualize your roadmaps. To truly, embrace Roadmapping as part of your Enterprise Architecture practice, you need to make sure TOGAF® and ArchiMate® are enhanced. This blog series will outline 3 specific areas of Roadmapping you should be focussing on to obtain and support a full Roadmapping capability:
1. Current versus Future State Architectures
In this post, we look at how to build roadmaps that represent the current state of the business and how future states are modelled.
2. Work packages and timelines
Part 2 is about producing work packages that represent pieces of work and how these tie to roadmaps to drive change.
3. Lifecycles and Heatmaps
Lastly, we look at the different lifecycles that components of our business and IT landscape journey through, and how we can ask analytical questions that help us make better business decisions.
Subscribe to our feed to receive the next post: Current versus Future State Architectures.
Or if you’re keen to learn more already download the Roadmapping whitepaper
What does an Enterprise Architecture Function do, and is Mine Broken?
http://eavoices.com/2013/12/31/what-does-an-enterprise-architecture-function-do-and-is-mine-broken/
Graphic: A Generalised Operating Model for Enterprise Architecture, Source: Steve Nimmons
domingo, 16 de marzo de 2014
sábado, 15 de marzo de 2014
jueves, 13 de marzo de 2014
The Architectural Vision Is What Executives Need From Enterprise Architects
The Architectural Vision Is What Executives Need From Enterprise Architects
Traditionally building architects have learned and communicated through the architectural vision. Selling this vision to clients became the method by which a building architect became recognized. In the early 20th century this consisted of examples, like Frank Lloyd Wrights mile high skyscraper, that would inspire public imagination. It would inspire professionals to become better architects. It would inspire the profession to reach for even greater heights.
In enterprise architecture we occasionally have some of these visions. They are simple and direct, but inspire us. Different than the blueprints that are talked about within the current frameworks, the vision captures the essence of the architecture in a concise manner that is understood by enterprise architects and their clients. It includes the reasoning for design choices. It is framed within the context of business through and understanding of its link through the operational model.
Businessmen are experts in seeing value. They will always talk about their return on investment, cost control, and revenue. Only those in business understand that this is just the metrics for the game. What businessmen really thrive on is perception. This is why business is so interested in enterprise architecture. The metrics they will justify and figure out. The architectural vision is what they need enterprise architects for!
We as professional enterprise architects seek to create understanding, develop a common thought space and, change hearts and minds. To that end, this site is not about collecting design diagrams but rather those architectural visions, stakeholder communication, and decision support artifacts that not only enable enterprise architects to be successful but will change the way people think about enterprise architecture, including core capabilities of business architects and enterprise architects.
Business Architects:
- Organizational Context – Impacting the formal structure, work management practices, human resource policies, leadership, and culture
- Corporate Vision – Mapping and alignment with the mission, objectives, goals, tactics, and strategies
- Value Chains – Strengthening alliances, capabilities, services, and processes by determining the return on technology investments.
- Plan – Rationalizing roadmap investments with respect to capabilities, resources, and competencies
- Marketplace – Recognizing internal and external competitive forces that determine the product/service offerings and their relationship
- Language – Defining the glossary, taxonomies, concepts, patterns, and references used to frame the organization
Enterprise Architects:
- Aligning strategic and operational views of business
- Driving the technology vision
- Transforming and automating operations
- Facilitating and governing organizational change
- Mitigating risk
- Overseeing investments
- Managing the architecture
- Integrating people, processes, and technology
Business Architecture is Part of Enterprise Architecture
Business Context
The business context of EA is formed of:
- A vision of the future state. At Gartner, we call this the Common Requirements Vision. This deliverable is typically 10-12 pages and explicitly connects environmental trends, business strategies and requirements of business process and IT together in priority matrices. This is a conceptual level document that requires confirmation of the target state, and its associated priorities, by the top of the governance decision-makers – typically, the people who decide how to allocate resources in the organization.
- A root, anchor model. The highest visualization of the enterprise, recognizable to the business, may be in the form of a business operating model, a hyper-extended view of the business ecosystem, business capability maps, a federated model or some combination of these for particular stakeholders. All business processes, information, applications, solutions, technologies, people skills, people, other entities, are overlaid upon and disaggregated from this root, anchor, model.
- A set of guiding principles. These shape the investment and action behaviors of all those who seek to select, create, and implement anything within any EA viewpoint.
Unfortunately, some have conflated this business-context package with the work done in the business architecture viewpoint of EA. These folks have mistakenly lured other EA practitioners into believing one or more of these myths:
- I can continue to do technology architecture without having a business context
- Business architecture is something completely separate from enterprise architecture.
- EA is for IT only.
Zachman framework
http://www.mel.nist.gov/msid/SSP/standard_landscape/Zachman.html
WHY
Motivation
WHAT
Structure/Data
HOW
Function/Activities
WHERE
Network
WHO
People
WHEN
Time
SCOPE
Cell details
Cell details
Cell details
Cell details
Cell details
Cell details
Contextual
List of business goals/statistics
List of things important to the business
List of processes the business performs
List of locations where business operates
List of organizations important to business
List of events significant to the business
Planner's view
Enterprise vision
Most significant business concepts
Missions
International places where organization is situated
Human resources
Overall annual planning
Motivation identification
Resource identification
Function identitication
Network identification
Organization identitication
Timing identification
Example question:Why should industries reduce hazardous chemicals in products?
Example question:What hazardous chemicals products must not contain?
Example question:How to measure concentration of listed chemicals in all parts?
Example question: Where (geographical regions) is this standard applicable?
Example question:Who can certify our products to this standard?
Example question:Which phases of the product lifecycle are affected by this standard?
RoHS
Why
How
What
Who
Where
When
Context
Example question: Why should we (industries) reduce hazardous chemicals in products?
Example question: How to measure concentration of listed chemicals in all detachable parts?
Example question: What hazardous chemicals products must not contain?
Example question: Who can certify our products to this standard?
Example question: Where (geographical regions) is this standard applicable?
Example question: Which phases of the product lifecycle are affected by this standard?
Conceptual
Example question: Why hazardous waste must be reduced by x%? Why products must not contain hazardous substances more than x%?
Example question: How to create chemical concentration information from bill of materials?
Example question: What is the definition of a “detachable part?”
Example question: Who can test product samples and give material concentration data?
Example question: Example question: Where to gather information related to this standard for different geographical regions?
Example question: When can material concentrations be measured (raw material stage, before assembly or after assembly)?
Logical
Example question: Why market tendencies are moving towards environment friendly products (Effect of hazardous chemicals on environment)?
Example question: How to separate product parts for inspection based on bill of materials?
Example question: What information must be submitted for inspection at each stage of production?
What information must be disclosed and recorded?
Example question: Who can perform material analysis for different parts of a product?
Example question: Where can we find laws related to product disassembly for various geographical regions?
Example question: When can we collect information of parts from different suppliers?
Physical
Example question: Why should we chart and compare market shifts - importance and effect of reducing hazardous substance?
Example question: How to analyze each part? How to compare substance concentrations between products?
Example question: What are the significant part types to be concerned about (e.g. solder, plug, etc.) for this standard?
Example question: Who are inspection agencies in this area? Who are compliant parts suppliers?
Example question: Where can we find restrictions on part types and substance used?
Example question: When should we obtain compliance certification?
Detail
Example question: Why is it important to perform cost-to-profit analysis of compliance for a product?
Example question: How to collect and compose data for final analysis?
How to obtain final certification?
Example question: What are the commonly used parts that contain hazardous substances? What replacements are available for these parts?
Example question: Who are involved in reporting for compliance certification?
Who can give guidance for compliance?
Example question: Where can compliant products be sold?
Example question: When will market mature for this standard?
Home page | NIST.gov | Contact | Disclaimer
miércoles, 12 de marzo de 2014
martes, 11 de marzo de 2014
Business Architecture and Value Stream
With a Business Architecture built with integrated value streams, you can build a value chain as defined above. For example, looking inside a typical mid-size, “build-to-order” manufacturer, you will find the following sixteen value streams:
- Prospect to Customer
- Order to Cash
- Manufacturing to Distribution
- Request to Service
- Insight to Strategy
- Vision to eBusiness Enterprise
- Concept to Development
- Initiative to Results
- Relationship to Partnership
- Forecast to Plan
- Requisition to Payables
- Resource Availability to Consumption
- Acquisition to Obsolescence
- Financial Close to Reporting
- Recruitment to Retirement
- Awareness to Prevention
Each value stream contains several integrated components. For example, in the Order to Cash value stream, you have four integrated components: Fulfill Order, Change Order, Review Order and Return Order. Some of these value stream components are the building blocks for a value chain. A value chain is not a collection of independent activities but a system of interdependent activities. Michael Porter first wrote about value chains back in 1985. His timeless ideas are enjoying a revival, perhaps having been forsaken by the focus on the explosive growth of the Internet during the past several years. A value chain is fundamental to the strategy, not an option merely for consideration.
The value chain and value stream are different just as illustrated in the earlier definitions. A value chain is more complex than a value stream and generally composed of value stream components. The most important differentiator is their purpose! As just defined, the value stream has a clear purpose; to delight the customer. The value chain has a clear purpose; to gain a competitive advantage. And both are important strategic elements. It is far more difficult to effectively and efficiently achieve the demands of a business unit’s strategic initiatives without a well defined value chain and value streams.
http://www.bainstitute.org/resources/articles/business-architecture-value-streams-and-value-chains
Capabilities Links
Capability
Value Stream
http://www.cutter.com/content-and-analysis/resource-centers/enterprise-architecture/sample-our-research/ear1102.html
http://www.bainstitute.org/resources/articles/capabilities-value-streams-business-architectures-essential-alliance
http://www.businessarchitectureguild.org/Resources/Documents/Business%20Architecture%20is%20THE%20REAL%20Tie%20that%20Binds.pdf
http://www.linkedin.com/groups/Capability-mapping-4379346.S.5840228104378802176?trk=groups_most_recent-0-b-ttl&goback=%2Egmr_4379346
lunes, 10 de marzo de 2014
Enterprise Architecture in the Software-Defined Data Center
. Enterprise architecture, after all, is a means to enhance business functionality,
Enterprise Architecture in the Software-Defined Data Center
domingo, 9 de marzo de 2014
EA RoadMap Links
http://eavoices.com/2013/07/29/how-to-build-a-roadmap-sequence/
http://www.ibm.com/developerworks/rational/library/enterprise-architecture-maximum-value/
http://pragmaticarchitect.wordpress.com/2013/06/11/how-to-build-a-roadmap-gap-analysis/
http://www.bredemeyer.com/pdf_files/Presentations/EnterpriseArchitectureAsCapabilitiesArch.pdf
What is the purpose of Enterprise Architecture? Building models or solving Enterprise problems?
http://www.linkedin.com/groupItem?view=&gid=84758&type=member&item=211842459&goback=%2Egmr_84758
Chris
Corporate stra
The purpose of EA is to enhance enterprise performance, through the innovations that people invest in.
Producing models to illustrate how that will happen in practice is one of the capabilities need for success, but isn't the core purpose of EA.
A particular challenge facing Enteprise Architects is that an enterprise (unlike a building, a landscape, etc) is not a physical entity, so producing models that are meaningful analogy for the enterprise depends on an especially good understanding of the audience
Traceability in enterprise architecture
http://www.managewithoutthem.com/blog/?p=105
The three fifteen step plan for solving your enterprise architecture issue is as follows:
- Hire a real enterprise architect
- Establish only ‘dotted-line’ reporting to the enterprise architect
- Use the phrase ‘enterprise architecture’ only to refer to ‘enterprise business architecture’
- Establish ‘planned traceability’ from the EA to project documentation
- Establish ‘planned traceability’ from the EA to system documentation
- Establish ‘planned traceability’ from the EA to software development life-cycle (SDLC) documentation
- Hold a workshop to established a baseline enterprise [business] architecture
- Schedule reviews of traceability each 6 months for each application system
- Include traceability reviews in the organizations project methodology at each phase gate
- Schedule a review of the baseline enterprise [business] architecture yearly
- Report, monthly, all EA traceability analytics
- Publish a quarterly analysis of EA traceability analytics
- Publish a whitepaper on how to interpret EA traceability analytics
- Co-sponsor at least one project concept / idea per year with a business growth outcome based on EA-level transformation
- Sponsor at least one project concept / idea per year with a IT efficiency outcome based on EA analysis and / or improving one or more measured based on traceability analytics
sábado, 8 de marzo de 2014
viernes, 7 de marzo de 2014
jueves, 6 de marzo de 2014
martes, 4 de marzo de 2014
Strategy and Execution Belong Together
http://resources.troux.com/blog/bid/102984/Strategy-and-Execution-Belong-Together
Strategy and Execution Belong Together
Business Technology Strategy Template
Here’s a riddle: What is it that almost every organization believes it needs, many organizations have, and few organizations use? The answer is an IT strategy.
CEOs and CFOs task new CIOs and old CIOs alike with developing an IT strategy. But despite the millions of dollars, pounds, euros, and yen spent on creating IT strategy every year, few of these strategies will be put to effective use. The IT strategy is the foundation upon which CIOs communicate the value of IT across the enterprise. Despite this, or perhaps because of this, only 18% of organizations have IT teams that communicate the value of IT effectively.
And one of the most common questions I receive from clients since publishing the Business Technology Strategic Planning Playbook is "do you have a plan template we can use?" At last I can answer, "yes - here it is!"
What differentiates a good business technology strategy?
The ideal BT strategy is one that clearly connects technology spending with achieving the goals of the enterprise. In developing any strategy, it is important to begin with a deep understanding of the business vision, mission, values, and goals. Effective business technology strategy must be anchored in the business goals since the strategy effectively sets out the path to achieve the goals - the BT strategy template clearly presents the choices being made in technology direction for the organization and makes it easy to see how these choices will help the organization achieve the goals.
A good strategy is one that is widely understood and consistently applied toward achieving the goals of the enterprise. The “strategy document” represents a challenge for IT as it must serve as both a marketing document to be shared with non-IT leaders and also as a set of practical guidelines for IT professionals. For this reason, Forrester recommends creating at least two documents: First the BT strategic plan – think of this as the brand marketing brochure for IT – it clearly lays out how IT will bring value to the enterprise and how this value will be measured; second, the IT operational plan – this sets out the choices IT leaders must make in order to effectively implement the BT strategy.
In 2012 Forrester assembled the best components from the many strategies reviewed over the years and, in conjunction with Forrester Leadership Boards CIO members, identified the key contents for an effective BT and IT strategy.
Business Technology Strategy elements must walk the reader/listener through the strategy in logical steps beginning with business goals and ending with a flexible technology roadmap that lays out the timing of the strategy implementation. This strategic plan must continuously evolve with the changing needs of the business – as such it must be less of a fixed investment plan for the next X years and more a set of strategic guidelines to help shape future technology decisions. The essential elements of the business technology strategic plan include:
- The executive summary. This one slide (or page) summarizes the essence of the strategy in a succinct form. It should be possible for someone to read the executive summary and have a clear understanding of what the rest of the document will communicate. If the document is a strategy proposal, summarize the business goals and the high-level strategies recommended to achieve them. If the document is a presentation of the choices that have already been made, then it’s important to set out why these choices were made, including the expected business impact.
- The business vision, mission, and values. After the executive summary, comes the strategy document itself. Just as we did in the summary, begin with the things that are important to the entire organization. By beginning with business vision, mission, and values you remind everyone that the purpose of this strategy is to achieve these things – nothing else.
- The business goals and assumptions. If you’re lucky, your organization has clearly defined business goals. If not, you will be stating the assumptions you have made around business goals for the next one to five years. Everything that follows in the strategy document connects back to these business goals and assumptions.
- A core structure tailored to your business. Although every strategy is unique, pick from these common elements of business technology strategies:
- Major market drivers and economic/market trends with expected business impacts.
- People and demographic trends with expected business impact.
- Business and market trends with expected business impact.
- Geopolitical trends with expected business impact.
- Emerging technology trends with expected business impact.
- PEST Analysis (Political, economic, social, and technological).
- SWOT Analysis (organizational and external environment and competition).
- Business Capabilities (highest level capability map).
- Identified strategic capabilities with an assessment of each (Green/Yellow/Red).
- Divisional goals (1-5 years).
- Individual Divisional Capabilities.
- Identified strategic capabilities with an assessment of each (Green/Yellow/Red).
- Business strategies to achieve goals.
- Changes in business capabilities.
- Assumptions.
- Investments in people, process, and technology.
- Business technology roadmap.
- Scenario plans.
- Impact on strategies for different scenarios.
I encourage you to download the BT Strategic Planning template - it's a Microsoft PowerPoint doc (fee for non-clients). The template is a skeleton – pick what you like and discard the rest. Customize the template for your own business. And most important of all, develop several versions of your presentation to suit the different audiences for your material.
Do let me know what you think. Leave comments here or in the discussion forum. Let me know what you would add. And if you have artifacts you think would be helpful for others, feel free to send them to me. We'll potentially share your ideas in the next version of the template.
If you use the template, I'd love to see your final versions (under NDA as needed of course).
Enterprise Architecture for Strong Organizations
Enterprise Architecture is a structured approach to innovate your organization, align business and IT, and become more agile. You have deep insight, and reduce IT risks and costs.
Drive change and innovation
A lot of organizations are lacking flexibility to support business transformation. Processes and IT landscapes are rigid and complex, and insight into the organizational structure is limited. This makes it hard to reduce costs, make grounded investment decisions, govern IT, and manage risks and compliance. Furthermore, communication with stakeholders is often cumbersome.
Why Enterprise Architecture?
To drive organizational change and innovation, people need a structured approach, a language and the tools to get strategic insight into the organization. Enterprise Architecture captures and visualizes the different business and IT domains, and their relationships. Enterprise Architecture facilitates change impact analysis, and helps you to communicate between different stakeholders and departments.
Benefits
- Innovate the organization and improve quality, reduce costs, and increase agility
- Align Business and IT by translating strategy into change
- Strategic insight into your organization and its complex dependencies
- Structured transformation planning with change impact analysis
- Increase stakeholder support with clear communication
- Improve IT management by reducing complexity
Enterprise Architecture Management by BiZZdesign
Enterprise Architecture Management is a comprehensive, integrated, and flexible approach to Enterprise Architecture by BiZZdesign, consisting of:
- Structured methods for implementing and using EA, e.g. TOGAF
- Consistent modeling language ArchiMate for mutual understanding and clear communication between different stakeholders
- Software tool BiZZdesign Architect for fast and clear modeling, analyzing and visualizing architectures
- Consultancy and Training
lunes, 3 de marzo de 2014
sábado, 1 de marzo de 2014
Will The Real Business Architect please stand up?
During a presentation on Business Architecture at Forrester's Enterprise Architecture Forum in London last week, someone asked the question - 'just who are these Business Architects anyway?' A couple of people in the audience dared to raise their hands and claimed to be this new breed of professional, but where did they come from and are they really doing Business Architecture?
I believe that there are at least 3 breeds who now claim to be Business Architects.
- The Enterprise Business Architect
- The Domain Business Architect
- The Project Business Architect a.k.a the Business Analyst
So, let's make it clear - Business Architecture is not something you do at the Project level. Forrester agrees that Business Architects are not Business Analysts. In 'The Up-And-Coming Business Architect' by Jeff Scott and Katie Smillie, they say:
"Forrester believes that these roles are quite distinct, with business architects designing and analyzing the "what" of the business at a higher, more strategic, and often enterprisewide level, while business analysts typically contribute to the "how" of business operations, processes, and projects."
Also, if we look at how the Business Architecture Community defines Business Architecture, as:
"A disciplined approach to creating and maintaining a set of business-owned information assets that serve as a blueprint for the planning and execution of strategy.
-
First and foremost, Business Architecture is developed by the business for the business.
-
Business Architecture provides a common, enterprise-level business language and framework for documenting how the business is structured."
It is clear from this definition that Business Architecture is about the planning and execution of strategy, which is usually done at the Enterprise and Domain or Line-Of-Business levels, and not at the Project level.
So, lets now look at this in more detail and try to understand what artefacts you may find in a Business Architecture at the different levels. In the following framework I've listed artefacts from an Architectural perspective, i.e. Contextual provides the 'Why?',Conceptual states the 'What?', Logical says 'How?', and Physical says 'With What?'
At the Enterprise level, given the Business Goals, the Business Architect is focused on strategic business modelling and planning for the whole business. At the Domain level, given the Enterprise Business Strategy, the Business Architect develops strategy, business models and roadmaps for the specific domain or line-of-business. Where the Domain is IT, the focus is therefore on the IT Strategy and execution through the Application portfolio. This brings us to the Project level, where the Business Architecture defined at the Enterprise and Domain levels, together with the Technical Architecture, provides the Enterprise Architecture context for the project. In reality, the context for Projects can be far more complex and can include many other sources, and the artefacts shown are not a comprehensive set for projects. But, this is not a blog about project analysis and design, our focus is Business Architecture, so in future posts we'll be looking at the artefacts shown at the Enterprise and Domain levels in much more detail.
Posted by Steve Bacallat 04:32
