Skip to main content

Article Types and Submission Process

Enable Architect welcomes original or republished (with permission) articles from the perspective of Architects in technology-centric roles. This includes a wide variety of topics on technology, career development, productivity, and more. 

Article types

Guide to the 6 types of articles on Enable Architect

The following sections describe the different types of articles that a contributor can create for Enable Architect. The article types are intended to be suggestions to help scope a proposal. Different forms of submission are welcome. These types of submissions tend to be faster to process and publish, which has its advantages.


Typically a news piece is ~500 words in length and reports a recent event, technology, or technique relevant to enterprise architecture. A news piece answers the 6 basic questions asked when reporting on a topic: Who? What? Where? When? Why? How?

The writing style should be concise yet engaging and focused on presenting the facts at hand.

An important note for all articles for this audience: no architectural news or consideration is either "good" or "bad." Consider all tradeoffs, and provide viable architectural scenarios throughout the article where those tradeoffs are relevant.

Example: Examples of edge computing: how cloud architects are benefiting from cloud-to-edge architecture

Personal Experience/Opinion

Typically an opinion piece is between 500 - 750 words in length. An opinion piece expresses a point of view or impression of a practice, technology, or technique relevant to enterprise architecture. Its role is one of personal connection: authors are encouraged to use the first-person ("I" statements) or speak to the readers directly ("you" statements).

Any arguments or assertions made in an opinion piece must be justified by facts and examples. The topic or thinking presented in an opinion piece can be strongly held, though all writing must be polite as we outline in our guidelines

Also important to note, this publication prefers vendor-neutral topics. For instance, suggest a necessary functionality to a solution rather than propose a specific vendor solution or tool as the only optimal answer.

Example: How I became a Data Architect | Enable Architect or What type of Data Architect should you hire?


Typically a step or listicle piece is between 500 - 750 words in length. The piece is segmented into a series of steps or list items that are focused on a specific topic. The piece should have a short introduction that provided context to the content and a conclusion that reiterate the main takeaways. Each item in the list should be described using short yet engaging language.

This format can be incredibly effective for providing context for those new to a concept or technology.

Example: 5 processor architectures making machine learning a reality for edge computing


Typically an opinion piece is between 500 - 1500 words in length. A didactic/instructional piece teaches the reader how to do something relevant to enterprise architecture.

The language needs to be clear and unambiguous. Writers are encouraged to use illustrations to reinforce the concepts and techniques being described in the piece.

Example: How to get hired as an Enterprise Architect in 2021


Typically an opinion piece is between 500 - 1500 words in length. An analysis piece investigates a technology or process and then provides commentary about the topic of interest.

It is recommended to analyze a technology or process in terms of benefits and challenges. Analysis pieces tend to be read by Architects that are considering or in the process of adopting a technology and want to get a balanced, informed assessment of the subject at hand. Note that we do not accept product reviews at this time, but rather a discussion of its architectural pattern. 

Example: Architectural messaging patterns: an illustrated guide


Architect's Guide

This series of articles are typically 1000 words or more in length. An architect's guide will provide a thorough investigation of a topic designed to be a key resource for one or more types of IT Architect.

It is recommended to crispy scope the level of abstraction the guide intends to explore. For example, if a guide explores load balancing architectures, it will not also guide a user into deploying a load balance (the latter being a separate article from the former). Guides, like all deep explorations on Enable Architect, discusses a technology or process in terms of benefits and challenges.

Guide pieces tend to be read by Architects that are looking for a canonical reference and want to get a balanced, informed assessment of the subject at hand. Note that we do not accept product guides at this time, but rather a discussion of its architectural pattern. 

Example: An Architect's guide to APIs: SOAP, REST, GraphQL, and gRPC 

Editorial process

The following illustration describes the editorial process used by Enable Architect for escalating an article from contributor concept to published piece. The details of each phase in the process follow.

Submission flow chart for Enable Architect

1. Identify topic with a working title

The contributor identifies an article topic and creates a working title for the intended piece and anticipated word count. The important part of this phase is a clear pitch: what do you want to cover and does it fit any of the patterns above?

2. Enlist editorial support

The contributor reviews the plans for the intended article with an Enable Architect editor. The editor will provide support in terms of consultative guidance, organizing the article, and creating the content of the intended article should the contributor desire such assistance.

3. Decide on draft delivery date

The editor and contributor will decide upon a delivery date for a draft submission of the intended article. The editor will provide regular reminders if it supports the author's personal goals around publishing an article.

4. Create a general outline

The contributor creates a general outline of the intended article. The outline should have at least 3 first-level headings and include an introduction and a conclusion.

5. Write a draft

The contributor writes the draft, with editorial support, if so desired.

6. Submit a draft

The contributor submits a draft of the article to the editor. The contributor notifies the editor that the draft is ready for review.

7. Technical edit

The submission is reviewed by a technical editor for technical clarity and accuracy.

8. Copy edit

The submission is edited by a copy editor in terms of spelling, grammar, and conformity to the site's editorial style.

9. Contributor review

The edited draft is entered into the Enable Architect content management system (CMS). The contributor is notified that the submission is ready for final review. The contributor reviews the work for accuracy in terms of intention and information.

Contributors have the final say on the exact wording used in the article, though editors will have the final say on the title and URL. Changes can be requested at this point and will move on after a final consensus is met or a time period has passed without a response.

10. Release

The Managing Editor sets a publication date for the submission. The Managing Editor will do their best to keep the author informed on the final publication date and initial readership of the piece, though they may need a reminder from the author. 

Final: Share

Congratulations, you're officially a published author on Enable Architect!

Our publication will share your work across all available channels inside and outside of Red Hat. All authors are encouraged to share their articles across their networks as well.