Inside Architecture

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

Browse by Tags

Tagged Content List
  • Blog Post: Should Business Architects use the Business Model Canvas at the Program level?

    In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture.  In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business...
  • Blog Post: Analysis, Synthesis, and Scope: Business Architecture vs. Business Analysis, part two

    A few days ago, I quickly dashed off a post on the difference between a business architect and a business analyst .  The reaction was immediate and rather vociferous.  The IIBA took me to task for saying that a business architect is NOT a business analyst.  In addition, Tom Graves (Enterprise...
  • Blog Post: The difference between business architect and business analyst

    [ Author’s note: within an hour of posting the following article, Kevin Brennen of the IIBA dry-roasted the post on his own blog. You can find a link to his entry here: Business Architecture is Business Analysis . I have made an attempt to fix a few of the most egregious errors in the post, and...
  • Blog Post: Time-to-Release – the missing System Quality Attribute

    I’ve been looking at different ways to implement the ATAM method these past few weeks.  Why?  Because I’m looking at different ways to evaluate software architecture and I’m a fan of the ATAM method pioneered at the Software Engineering Institute at Carnegie Mellon University.  Along the...
  • Blog Post: On the Hunt for the One-Page View of an Enterprise

    I am currently noodling the idea of a one-page view of my employer (Microsoft) for the purpose of rationalizing the sharing of services across business units and business models.  (If you understood the previous sentence, you are probably an enterprise architect, even if that is Not your title)...
  • Blog Post: Perhaps the most valuable conversation you can have… starts with a question

    A co-worker and I spent an hour doing something innovative… and no, it was not part of a “ Google 20% strategy .”  We spent an hour discussing PKI, personal identity, and trust of both “passive content” (like documents) and “active content” (like applications) as that content originates from one...
  • Blog Post: When demand management is confused with alignment…

    One of the most common, and reasonable, mechanisms for achieving clarity on the roadmap for a single platform is “demand management.”  It is also one of the areas of IT that is both rapidly evolving and poorly defined.  I’d like to offer an opinion about what demand management is, and is not...
  • Blog Post: Building less than you know you’ll need

    In the past, I’ve been guilty of this sin: gold-plating.  Back when I was a solution architect, I would (often) think about the things that the business is going to need, but never asked for.  I would occasionally include elements in the design to support those needs, even though the business...
  • Blog Post: How the Program Management Office Views Enterprise Architecture…

    There’s an interesting analysis available through the PMO Executive Board on “Project Interdependencies.”  In the problem statement, the author correctly observes: As the volume and size of projects grow, the old problem of managing project and program interdependencies is becoming more acute: three...
  • Blog Post: The cost of “SOA-fication”

    No, Virginia, there is no SOA Santa Clause.  SOA is not free. That said, if I’m changing a system to meet new needs, and I’m substantially refactoring a section of the code to deliver to those needs, SOA doesn’t have to be wildly expensive either. The myth of “expensive SOA” is just that: a myth...
  • Blog Post: Business Architecture --- includes process architecture?

    Debasish Mishra, a colleague of mine, posted recently that we should let Business Architects out of the “Business Process Optimization Prison.”  ( link )  He raises some good points.  Chief among them is whether process optimization should be the sole focus of the business architect. ...
  • Blog Post: When feasibility of integration is a measure of capability…

    One of the jobs of an enterprise architect is to evaluate the business capabilities of an area of the business and determine if those capabilities are either strong, capable, or insufficient.  But what to do when two areas of the business overlap? In some cases, as in mergers, or even consolidation...
  • Blog Post: Modeling User Experience Scenarios

    I’m working on modeling some requirements for a document management system.  I’m a big fan of using models to represent every element, from goals and strategies through to business processes.  From there, I model use cases and requirements and on down to system components that fulfill those...
  • Blog Post: Make IT appear as simple as possible, but not simpler

    Sometimes I hear a complaint from an IT architect who wants to have direct conversations with “the business” or “the customer” but, for some reason (usually bureaucratic), they cannot.  There is a team of analysts or project managers that they are supposed to talk to.  The original objective...
  • Blog Post: The Process of Strategic Planning

    I'm a process guy. I'm not a big fan of the claims of process management software, but I'm a huge fan of developing and using process models to organize the activities of people, and then to drive the requirements for software from those models. So when I was asked to look into the processes for Strategic...
  • Blog Post: Collecting requirements from business processes

    Ah, the sweet sounds of success.  I got the opportunity, this week, to collect a list of requirements for a strategic planning tool that we will license and use within Microsoft IT (COTS).  The fact that I got to collect requirements is not particularly cool.  What is cool is this: I made...
  • Blog Post: Update to root cause analysis for poor software requirements

    Just a quick note. After reading through some of the feedback on my recent post on " the root causes of poor software requirements, " I had to agree with some of the respondents: I had forgotten a branch in the analysis. So, for the past week, I've been stealing a few minutes here and there to review...
  • Blog Post: Understanding the root causes of poor software requirements

    If I had a nickel for every time I've heard a developer complain about poor quality requirements, I'd... well... have a lot of nickels.  Let's look, for a moment, at the root causes of poor requirements and business rules.  While I consider this to be a business problem, and not a technology...
  • Blog Post: The business value of elegant design

    In my last post , I highlighted the design process, suggesting that designers and architects should consider using creativity, in addition to methods and patterns, to build a truly useful system.  In this one, I'd like to talk about the business value of this idea.  What does the business get...
  • Blog Post: Non-Functional Requirements: the "All-Other" classification

    I've seen various taxonomies of requirements.  Like all taxonomies, any set of requirement types exists to classify or partition requirements into coherent groups for further analysis.  Most break down the list of requirements into things reminiscent of "who or where the requirement comes...
  • Blog Post: Clarifying the Use Case

    A Use case is a cool thing.  A little too cool.  The term has been occasionally misused, and in some respects, that misuse diminishes the value of a use case.  To succeed, we have to know what a use case is.   When you are done reading this post , you will still know what a use...
  • Blog Post: Using Business Process Models as the source for software requirements

    Requirements elicitation is a critical, yet under-appreciated, activity.  A core capability of business analysts, the ability to get the customers to describe what they want, and need, is both a science and an art.  Requirements elicitation requires equal measures of careful planning, situational...
  • Blog Post: Building Conceptual Models, Building Relationships

    Building teamwork, at the enterprise level, is a tricky thing. As a project team comes together to solve a problem, hopefully you find yourself in the same position that I've found myself in many times: with smart experienced people, all motivated to succeed.  Microsoft IT is chock-full of folks...
  • Blog Post: Open Question: Common vocabulary: Blessing or Curse?

    Requirements are an interesting thing.  We cannot assume that we understand the business, and their needs, so we 'elicit requirements.'  And we write them down.  But "the business" is a collection of different people, and in order to be clear, we need to make sure that everyone...
  • Blog Post: The Usefulness of the Use Case?

    I'm a big fan of use cases.  Great for describing how software is used, and puts context around the use of functionality that helps software developers to create solutions that will actually fit into human activities.  On the other hand, are there drawbacks to using use cases for flushing out...
Page 1 of 2 (30 items) 12