11 May 2008

Tidy Up, please tidy up here!

I've switched from Windows to Mac OS X about 2 years ago, at least at home, where I have enough influence to change things on a small scale. I've converted my mother's computer from Windows 95 to Mac a couple of years ago. We've upgraded from our PowerBook to the latest MacBook Pro four weeks ago. We have iPods, and soon the touchable version of it. We also own a Nano. We love Apple and the software on it. With one exception: Tidy Up! It's that program that makes me crazy. It's my fourth test run to clean up my iTunes library with it. Everything on a Mac is easy. TidyUp is not. I bought the full version because I believed the reviews in the Internet. That must all be great marketing talk from Hyperbolic Software, because it just does not work for me. It's not Tidy Up, it's Tidy Down!

04 May 2008

Thoughts on Technology Domains

So I have a plan: I want to start categorizing that huge pile of technologies in my company. Where do I start? How should I partition it? What has been done before me? Are there best practices already in the field of technology architecture management?

Separating the vast field of technologies in "buckets" helps to do the following:
  • Apply ownership and responsibilities to groups of technologies
  • Provide a governance framework based on these buckets, to foster standardization, reuse and provide the necessary processes to handle exceptions
  • Provide detailed "cost per topic" views (e.g. database technology costs, application server costs, etc.)
  • Create the basis for technology lifecycle management (e.g. decommissioning/phasing out of products, moving to new technologies, etc.)
The following domains are a "safe bet" to me, i.e. you will most probably not get a huge push back on them:
  • Base Infrastructure: Server and workplace hardware and operating systems, network components and services
  • Database: DBMS, Document Management Sytems
  • Middleware: Application servers, workflow and messaging infrastructure
  • Workplace: Laptop or desktop platform including hardware, operating system(s), and tools, with a focus on business users
  • Application and Service: Buy and inhouse developed applications including internal and external services, including all around integration and software development
The following domains are optional, depending on structure and size of your company:
  • Information Exchange: Most companies of today need a well managed platform to copy data between the applications.
  • Business Process & Workflow: Platforms and tools to provide process and workflow management features to either directly to users or to the applications
  • Information Exploitation: Platforms and tools to identify added value from our own data. Often, this is integrated in the Database domain
Domains that apply to all of the domains mentioned above (i.e. orthogonal to them) are:
  • Security: Mechanisms to protect and properly access applications, services and their data
  • Systems Management: Domain crossing tools and platforms to manage Swiss Re's runtime components
From what I've seen, such a structure os widely accepted in the market today. Apply this list to your technology portfolio and to your organizational setup.

Strategies for such domain structure differ between companies. Some might need a rigorous reduction to a small number of products, others might need a larger diversification to make sense to business. And here's the top down approach again - it is finally a call from business to define which domains are important to a company and how those domains need to be organized and managed.

Should Software Architects write code?

Gregor answers this nicely in https://youtu.be/31qcPwAv8Zw . Yes, they should. But not to create production code, but to grasp the idea and ...