Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

June, 2009

Posts
  • Inside Architecture

    Should some requirements be called out as “architectural” requirements?

    • 13 Comments

    Some methodologies of software architecture, including EWITA, attempt to describe architectural processes in a manner that is quite separate from the development of software.  Is that valid?

    To whit, the first step in the EWITA process is described as “architectural requirements.” Yet, there doesn’t seem to be any definition, on that site, about what criteria we’d use to decide if a requirement is architectural or not.  So if my job is to collect architectural requirements (hmmm…), then I have to ask, “what is an architectural requirement, and how is it different from some other kind of requirement?”

    Consider this analogy

    A few years ago, when I was considering making an addition to my home, we called an independent architect to come over and discuss details.  We talked about the functionality of the rooms, and where they would be attached to the house, and what changes we’d need to make to the rest of the house.  All of these requirements were shared with the architect, and he was planning to consider them all when creating a solution.

    So are requirements architectural if the client tells them to the architect?  I don’t think that is a useful definition.

    Are some requirements more inherently architectural than others?  Good question. 

    Some requirements came in the form of building codes.  Were those architectural?  Surely, they affect the architecture of the building, but so do requirements about function, size, and even the ease by which we would decorate a room.

    In software, the same problem occurs.  Business customers describe their use cases.  Sometimes we talk about using data from other systems. Other times, we talk about speed and performance.  Mostly we talk about functionality.  What the application will do, and how it will make their lives better. 

    I don’t differentiate requirements as “architectural” vs. something else.  It is not a distinction that I find useful.  My question, fair reader, is to you: do you have a practice of attributing your software requirements with a note that says “this one is architectural?”  If so, what logic do you use to flip that attribute to “true?” 

    I’m just not seeing it.

  • Inside Architecture

    The Semantic Language of Architecture

    • 1 Comments

    For most of the last decade, we’ve seen a steady growth in the use of a simple “recommended practice” in the world of software architecture.  Well known by it’s designation, IEEE-1471 is officially titled “Recommended Practice for Architectural Description of Software-Intensive Systems.”

    The standard defines words, mostly.  It answers the question: “What is Software Architecture” and does so in a simple and elegant manner using the concepts of model, view, and viewpoint.  It is also written in somewhat vague language, with the meaning of some terms being assumed and others inconsistently applied.  Creating a conceptual model from this document was no simpler than creating a model from a typical business document, even though it should have been. 

    Regardless of the relatively minor deficiencies of IEEE-1471, we find it a useful way to describe software architecture and our team in Microsoft IT has fully embraced the language and concepts of this simple and elegant approach.  In addition to embracing 1471, we extended 1471 by linking in key concepts from the UML, as well as other notions like “common viewpoint types,” “architectural description methods,” and modeling languages.

    A number of months ago, I created a small poster (designed to be printed in Tabloid size or larger on a color printer) that illustrates the value of this simple language.  Embedded in that poster is a conceptual model that illustrates what these terms mean in relation to one another.  I’m sharing the poster here, for others to benefit from.

    My goal is to provide a simple way for all architects to illustrate, share, learn from, and talk about the language of software architecture.  I hope that this poster finds its way into classrooms and team training sessions.  Feel free to use the poster as a way to communicate and share.  I did not author these concepts.  I’m simply trying to explain them.

    image

    Note: the diagram uses some of the notational conventions of UML, but not many.  If you understand the concepts of association, composition, and aggregation in the basic class model, you can read this diagram.  The verbs on the lines between concepts are written so that a reader can read the association by following the arrow. 

    If you’d like the IEEE-1471 Extended diagram, without the rest of the poster, simply click the image below.

    IEEE 1471 - extended

  • Inside Architecture

    Suggested Curriculum: MBA in Business Architecture

    • 11 Comments

    About a month back, I asked if it was time to create an MBA in Business Architecture. I’m going to follow up with a suggestion for a curriculum for such an odd degree.

    The degree is provocative on its face.  After all, an MBA is first and foremost, a business degree.  Yet most Enterprise Business Architects are employees of IT departments.  How do we mix the two?

    I honestly believe that the core business skills focused on in the MBA are necessary but not sufficient to be a good EA.  I believe that core technology skills are necessary but not sufficient either.  You need a mix of both.

    A good EA needs to be able to operate in both spheres: business and technology.  They need to have excellent skills in both.  That is why I wonder if the program at RMIT in Australia is sufficiently business oriented.  On the other hand, the McCombs school of business in Texas has an undergraduate degree that mixes business and engineering.  That seems interesting.  There is also a university in Switzerland that has a degree in Business Engineering, but I couldn’t get many details.

    The following curriculum suggestion was derived from two primary sources.  The first is the Austin Texas MBA program mentioned above.  The second is the listed curriculum of the Harvard Business School.  In a few cases, I copied the course descriptions verbatim from one of these two sites.  In most cases, I modified the course descriptions to represent the “flavor” that I would wish to see for a Business Architecture MBA. 

    Basic Modeling and the visual representation of business concepts Basic understanding of models, and using modeling to recognize, represent, and improve the information, relationships and clarity of business activities.  Students are introduced to Business Process Modeling, Computer systems modeling, Conceptual modeling, and the concept of metamodels.
    Financial Accounting Covers concepts and issues in the preparation and interpretation of financial statements and the use of financial information in evaluation and control of an organization.
    Financial Management Examines the theory and practice of corporate finance. The focus of the course is on investment and financing decisions. Structural impacts of financial decisions are described using models.  Major topics include risk and return, valuation, asset markets and market efficiency, capital budgeting, capital structure, dividend policy, agency considerations, and derivative securities.
    Business Structural Evaluation, Modeling, and Transition planning Operational Models are studied, along with transition strategies for companies moving from one operational model to another. Structural approaches to the division of responsibilities and the use of incentives and scorecards to drive organizational behavior are studied.  Students will be expected to develop a full enterprise model of an existing business or governmental institution from case studies and publically available information.
    Business, Government, and Economics

    This course introduces tools for studying the economic environment of business to help managers understand the implications for their companies. Students will learn the impact of: National income and balance of payment accounting, Exchange rate theory, Political regimes, and regional global integration issues.  These integration issues include: International trade, Foreign direct investment, Portfolio capital, and Global environmental issues.

    Marketing Management Studies three distinct marketing issues – market analysis, developing a marketing strategy, and constructing the appropriate marketing mix for a product. The course highlights the development and visual representation of action strategies, development of products and services, establishment of effective pricing, determination of distribution intensity, and promotion of business solutions. 
    Business Process Improvement / Lean / Six Sigma Examines the operational measurement view of business.  The first unit discusses statistical measurement systems for business.  The second unit focuses on business process understanding and modeling, along with methodologies for simplifying and improving business processes.   Students will be required to produce detailed BPMN models and then use Lean and Six Sigma techniques to improve them.
    Strategy Development and Alignment

    The objective of this course is to help students develop the skills for formulating strategy. Strategy development provides an understanding of a firm's operating environment, competitive advantage, customer value proposition, activity configuration, and balancing the risks and opportunities available to an enterprise with the business strategy in mind.  The first module focuses on  competitive positioning; understanding comparative costs; and addressing issues such as cannibalization, network externalities, and globalization.  The second module focuses on the analytical tools of business modeling, and the alignment of business structures and behavior to strategic concerns.

    Finance Based Decision Making and the Planning of IT investments Illustrates the essentials of managerial planning and control, for any business function, with a special focus on the planning and management of Information Technology investments.   This course examines topics like short-term and long-term decisions, activity based costing, strategic alignment, and benefits realization.
    Negotiation, Presentation, and Influence This course focuses on the communication skills that are critical to the success of the Enterprise Business Architect, including the ability to negotiate for success, the ability to understand concerns and inform stakeholders at all levels of an organization, and the ability to influence the decision making and outcomes of teams outside your direct control.
    Leadership and Corporate Accountability In this course, students learn about the complex responsibilities facing business leaders today. Using case studies that highlight difficult managerial decisions, the course examines the legal, ethical, and economic responsibilities of corporate leaders. It also teaches students about management and governance systems leaders can use to promote responsible conduct by companies and their employees, and shows how personal values can play a critical role in effective leadership.
    Enterprise Architecture Models and Frameworks This course focuses on the history, evolution, and comparative study of the uses of various frameworks that target the enterprise.  This includes discussions of the Zachman framework, eTOM, TOGAF, FEAF, MODAF, and others.  The development of mature Enterprise Architecture programs, and their relationship to various business functions including Information Technology, Strategic Planning, Human Resources, and Finance are studied.
    Business Architecture Patterns and Practices This course focuses on the specific terminology and practices used in the modern Business Architecture environment, including the use of heatmaps, capability maps, enterprise roadmaps, investment prioritization, IT portfolio management, Enterprise Project Management Office, and structures for corporate governance and compliance.
    Electives courses
    • Business Program and Project Management
    • Information Security
    • Statistics for Decision Making
    • Software Development Processes (from Waterfall to Agile)
    • Software Operations Management and IT Service Management
    • Manager’s Introduction to Software Development
    • Software Development Languages and Environments
    • Information Modeling and aspects of Data Design

    That’s my take on a potential degree program.  I know this is a bit off-topic for an Enterprise Architect, but it is good to illustrate a wish list sometimes. 

  • Inside Architecture

    reworking my Architecture blogroll

    • 4 Comments
    Many of the folks on my Architecture blog roll have been inactive, so I've dropped them.  There are other, newer blogs that may deserve attention.  If you know of a blog or wiki that covers Architectural issues, and you find it valuable, please send me the link so I can add it to my blog roll.  (Yes, you can nominate yourself).
Page 1 of 1 (4 items)