The New Jazz Thing - Vince Outlaw's Audblog
Tuesday, February 03, 2004
iPass Signs Deal with SAIC
iPass Signs Deal with SAIC: "“SAIC needed a mobility solution that not only could service our large employee population, but which would work with our existing IT infrastructure,” said Joe Secker, SAIC senior vice president and business manager of the Telecommunications Business Unit. “What we were hoping to find was a service that not only would meet our internal needs, but which would complement our client base as well.”"
There's that 'Business Unit' terminology popping up. First I've seen.
InfoWorld: IBM's Grady Booch on solving complexity: February 02, 2004: By Ed Scannell: Application Development
InfoWorld: IBM's Grady Booch on solving complexity: February 02, 2004: By Ed Scannell: Application Development
EACommunity - Information and Interaction for the Enterprise Architecture Community
EACommunity: Clyde Miner: IT Architecture - Where, What, Why?
Here's a simple article with a pretty darn simple view of an Enterprise Architecture. Here's are the components or layers,
Layer 1: Business Model - Products/Services Layer 2: Informational Model - Data Definition/Organization & Business Processes Layer 3: Operational Model - Organization & Resource Alignment Layer 4: Architectural Model - Overall IT Design Layer 5: Infrastructure - Tools/Products/ IT Processes
And a definition of where I'm looking at right now, the Informational Model (or layer),
An Informational Model identifies how the organization?s business works. Information/process analysts review the business model goals/outputs and determine what data, process entities and integration need to be defined to optimally achieve them. The emphasis is on information. The data and process structures of the organization (i.e., how the data works and reacts to various systematic behaviors) that produce and deliver information is considered. The informational model shows resources, processes, process interaction, atomic data, and data associations being used to drive the business today. It typically shows the lack of data integration."
One final interesting thing, is that this says you need to develop these in the order listed. Um....
Campaign Memo: When the Long Haul Is No Longer an Option
Campaign Memo: When the Long Haul Is No Longer an Option
Enterprise Architecture Validation, Institute For Enterprise Architecture Developments (IFEAD)
Enterprise Architecture Validation, Institute For Enterprise Architecture Developments (IFEAD)
The Role of Taxonomy in Enterprise Information Infrastructure
The Role of Taxonomy
in Enterprise Information Infrastructure
Technology: Enterprise Architecture
CIOinsight.com: Gary Bolles: This Old Infrastructure: Enterprise Architecture
An overview of different interpretations of EA and what it takes to get an EA project rolling. The main thing I'm seeing in each and every approach I've read is to start with one business initiative and build your EA program from there. But this seems to be the hardest part, especially when you are seeing lots of holes in the existing EA infrastructure. It would seem that it would be easy to at least first off identify the best practices in what components make up an EA and how to manage them, THEN apply those to one project and see where that gets you.
Anyway, I like this definition of EA (with a couple changes by me), from, by golly, a law called the IT Management Reform Act of 1996 (or Clinger-Cohen act), which explains EA this way,
"an integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the [organization's] strategic goals and information resources management goals."
I'd maybe change it to this...
"an integrated framework for evolving AND maintaining existing information technology and evaluating new information technology to achieve the [organization's] strategic goals and information resources management goals."
and this seems to ring as true to a goal as I've seen yet,
"enterprise architecture creates a blueprint that includes a set of standards toward which the organization gradually migrates, and it encourages process discipline that ensures no new technology is bought or developed unless it's directly linked to a specific business initiative."
The articles includes a section telling how important getting people, especially what he calls the 'business constituents', involved from the start. I see a real dilema here, especially when the IT folks running the EA effort have not been empowered at some point to know what the real business is. Traditional 'silos' of IT technology and knowledge have led to 'silos' of business knowledge among IT folks...we really know the business of the folks we support, but that may just be in our own IT silo. Some of the goals of EA efforts are to bring those business goals / processes that may be outside of our current perview (sp?) into the IT process, but if we haven't really addressed them before, how do we know who to address? The answer seems to be to cast-wide for the business needs of the company.
Lots to learn...and lots to learn about how to learn...
Google Search: information infrastructure enterprise architecture
Google Search: information infrastructure enterprise architecture
Here's where we're focusing my intial efforts.
